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

[Stephen Frost]

* 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.

> And we could then finally make geometry columns a simple view against 
> the system tables (maybe, not sure how that would work with views).

Indeed.  I think a view on the system tables would probably be fine, but
even if it's not for some reason you could always write a set-returning
pl/pgsql function that queries the system tables and could then be used
in a view.

	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
-------------- 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/59373c8a/attachment.sig>