[postgis-devel] Typmod Again
pramsey at cleverelephant.ca
Wed Jul 22 17:13:09 PDT 2009
Unless this cast I am seeing for things like varbit is the trick?
* 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.
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?
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?
> On Wed, Jul 22, 2009 at 4:50 PM, Stephen Frost<sfrost at snowman.net> wrote:
>> * 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?
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (GNU/Linux)
>> -----END PGP SIGNATURE-----
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
More information about the postgis-devel