* 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:
and on -hackers here:

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.



Attachment: signature.asc
Description: Digital signature

Reply via email to