[postgis-devel] [Fwd: Rethinking user-defined-typmod before it's too late]

Fri Jun 15 12:07:09 PDT 2007

* Stephen Frost (sfrost at snowman.net) wrote:
> * Paul Ramsey (pramsey at refractions.net) wrote:
> > Lots of handy uses for this... I wonder if we can have it be overloaded, so
> > 
> > geometry just gives you an unconstrained geometry
> > geometry(srid) gives you an srid constraint
> > geometry(srid,type) gives you ...
> 
> I'm not sure..  The second two should be fine but 'geometry' by itself
> might not be allowed when the system is expecting a typmod.  I'll ask
> about it in my next email though and see what response I get.

Actually, thinking about this a moment further, numeric does this and so
I'd expect that geometry could too.

We'll have to encode the actual typmod that's stored in the system
tables into 31bits at the moment it sounds like though.  Now, obviously,
we could have a side-table where we just use an integer lookup to handle
each type but I'd rather it just be encoded in the typmod.

So, given that the SRIDs only go up to around 32,000 right now, can we
limit the SRID to only 16 bits?  Then we'd have 16 bits to store the
type (which would be an enumerated set and take up only a few bits I'd
think) and the dimensions (are there ever more than just 2?).

I'm also asking Tom about maybe getting more room, but it sounds like an
implementation issue that's unlikely to change...

	Thanks,

		Stephen

> > Stephen Frost wrote:
> > >* Mark Cave-Ayland (mark.cave-ayland at ilande.co.uk) wrote:
> > >>Thought this would be interesting for fellow developers - as of 8.3,
> > >>there is now the facility to specify a typmod as part of a user-defined
> > >>type, e.g.
> > >>
> > >>CREATE TABLE foo AS (
> > >>	id bigint,
> > >>	the_geom geometry(4326)
> > >>);
> > >>
> > >>This could have some interesting uses for defining geometries with
> > >>coordinates systems and dimensionality....
> > >
> > >Even better, what Tom's proposing is making it a string, where you could
> > >then have something like:
> > >the_geom geometry(4326,POLYGON,2)
> > >
> > >Or at least, I think that's the case, and I've sent a follow-up email on
> > >this thread asking him about it already. :)
> > >
> > >	Thanks,
> > >
> > >		Stephen
> > >
> > >Content-Description: Forwarded message - Rethinking user-defined-typmod 
> > >before it's too late
> > >>Date: Fri, 15 Jun 2007 12:14:45 -0400
> > >>From: Tom Lane <tgl at sss.pgh.pa.us>
> > >>To: pgsql-hackers at postgreSQL.org
> > >>Subject: Rethinking user-defined-typmod before it's too late
> > >>
> > >>The current discussion about the tsearch-in-core patch has convinced me
> > >>that there are plausible use-cases for typmod values that aren't simple
> > >>integers.  For instance it could be sane for a type to want a locale or
> > >>language selection as a typmod, eg tsvector('ru') or tsvector('sv').
> > >>(I'm not saying we are actually going to do that to tsvector, just that
> > >>it's now clear to me that there are use-cases for such things.)
> > >>
> > >>Teodor's work a few months ago generalized things enough so that
> > >>something like this is within reach.  The grammar will actually allow
> > >>darn near anything for a typmod, since the grammar production is
> > >>expr_list to avoid shift/reduce conflict with the very similar-looking
> > >>productions for function calls.  The only place where we are
> > >>constraining what a typmod can be is that the defined API for
> > >>user-written typmodin functions is "integer array".
> > >>
> > >>At the time that patch was being worked on, I think I argued that
> > >>integer typmods were enough because you'd have to pack them into such a
> > >>small output representation anyway.  The hole in that logic is that you
> > >>might have a fairly small enumerated set of possibilities, but that
> > >>doesn't mean you want to make the user use a numeric code for them.
> > >>You could even make the typmod be an integer key for a lookup table,
> > >>if the set of possibilities is not hardwired.
> > >>
> > >>Since this code hasn't been released yet, the API isn't set in stone
> > >>... but as soon as we ship 8.3, it will be, or at least changing it will
> > >>be orders of magnitude more painful than it is today.  So, late as this
> > >>is in the devel cycle, I think now is the time to reconsider.
> > >>
> > >>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.
> > >>
> > >>Note that the typmodout side is already OK since it is defined to return
> > >>a string.
> > >>
> > >>Comments?
> > >>
> > >>			regards, tom lane
> > >
> > >>_______________________________________________
> > >>postgis-devel mailing list
> > >>postgis-devel at postgis.refractions.net
> > >>http://postgis.refractions.net/mailman/listinfo/postgis-devel
> > >
> > >
> > >------------------------------------------------------------------------
> > >
> > >_______________________________________________
> > >postgis-devel mailing list
> > >postgis-devel at postgis.refractions.net
> > >http://postgis.refractions.net/mailman/listinfo/postgis-devel
> > 
> > 
> > -- 
> > 
> >   Paul Ramsey
> >   Refractions Research
> >   http://www.refractions.net
> >   pramsey at refractions.net
> >   Phone: 250-383-3022
> >   Cell: 250-885-0632
> > _______________________________________________
> > postgis-devel mailing list
> > postgis-devel at postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-devel

> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20070615/70d54593/attachment.sig>