[postgis-devel] Typmod Again

[Paul Ramsey]

Unless this cast I am seeing for things like varbit is the trick?

/* varbit()
 * Converts a varbit() type to a specific internal length.
 * len is the maximum bitlength specified in the column definition.
 *
 * If doing implicit cast, raise error when source data is too long.
 * If doing explicit cast, silently truncate to max length.
 */
Datum
varbit(PG_FUNCTION_ARGS)
{
        VarBit     *arg = PG_GETARG_VARBIT_P(0);
        int32           len = PG_GETARG_INT32(1);
        bool            isExplicit = PG_GETARG_BOOL(2);

So is a geography case defined w/ parameters

geography(geography, typmod, bool)

what PgSQL calls before dropping the objects into place?

P.

On Wed, Jul 22, 2009 at 5:04 PM, Paul Ramsey<pramsey at cleverelephant.ca> wrote:
> 32 bits:
> Top 24 bits for SRID,
> Middle 6 bits for Type,
> Bottom 2 bits for Z/M flags.
>
> The difficulty is not doing typmod, it's doing it without breaking
> backwards compatibility. I'm also currently running into some oddness
> with PgSQL not handing me the typmod in the _in function (which is
> required to enforce the restriction), even though one is defined on
> the column.
>
> There's some issues in general with typmod, I fear, which is that a
> typmod is not a constraint. Where is it enforced? It seems like only
> in the _in function, which just protects the on inserts from text.
>
> If I do
>
> UPDATE mytable SET thegeom = ST_SetSRID(thegeom, 1111)
>
> and 1111 is not my SRID typmod, what happens?
>
> P.
>
> On Wed, Jul 22, 2009 at 4:50 PM, Stephen Frost<sfrost at snowman.net> wrote:
>> Paul,
>>
>> * Paul Ramsey (pramsey at opengeo.org) wrote:
>>> FYI, I'm implementing this stuff within the context of GEOGRAPHY,
>>> which allows us to sort of play with these ideas before rolling them
>>> onto GEOMETRY in a breaking way. I do think that trying to hew closer
>>> to the standards base for GEOMETRY when we do the 2.0 release would be
>>> a good idea, try to put all the breaking changes we can think of into
>>> one release.
>>
>> I've been meaning to work on the typmod stuff for quite some time, but
>> have just been way too busy. :/
>>
>> What's your implementation plan?  Will you be using a side-table for
>> each distinct typmod used in the system, or trying to encode the full
>> typmod into an integer?  If the dimension can be derived from the type,
>> it might be entirely possible to fit the rest into an integer, provided
>> an SRID isn't required to allow for a full integer itself.  I don't
>> recall ever getting an answer to how big an SRID is allowed to be..
>>
>> Do you need help with it?  Is there a spec somewhere already that
>> details your approach?
>>
>>        Thanks,
>>
>>                Stephen
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (GNU/Linux)
>>
>> iEYEARECAAYFAkpnpa8ACgkQrzgMPqB3kigLvwCfYzyhkjwnq8YQZx9zcwLd3zrX
>> SAYAoJSLvluH5Ce3rWMRKG8ia7OPYXe2
>> =IcJT
>> -----END PGP SIGNATURE-----
>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>>
>