Re: Rethinking user-defined-typmod before it's too late

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) 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(at)postgresql(dot)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