* Tom Lane ([EMAIL PROTECTED]) wrote: > I propose changing the typmodin signature to "typmodin(cstring[]) returns > int4", that is, the typmods will be passed as strings not integers. This > will incur a bit of extra conversion overhead for the normal uses where > the typmods are integers, but I think the gain in flexibility is worth > it. I'm inclined to make the code in parse_type.c take either integer > constants, simple string literals, or unqualified names as input --- > so you could write either tsvector('ru') or tsvector(ru) when using a > type that wants a nonintegral typmod. > Would this allow for 'multi-value' typmods for user-defined types? That's something that would greatly help and simplify PostGIS. It was brought up on the PostGIS lists here: http://postgis.refractions.net/pipermail/postgis-users/2006-September/013086.html and on -hackers here: http://www.mail-archive.com/pgsql-hackers@postgresql.org/msg81281.html
The 'geometry' type really needs to have a typmod which has the dimensions, SRID and type of the geometry. At the moment the PostGIS folks are using constraints and essentially a side-table to work around this, which gets really, really ugly. It sounds like this might work for them, and while it'd incur a bit of overhead to parse the string I'm pretty sure it'd be worth it. Thanks, Stephen
signature.asc
Description: Digital signature