[postgis-devel] Typmod: Making my Life Harder

Chris Hodgson chodgson at refractions.net
Mon Aug 3 13:38:50 PDT 2009


Can we leave the 2-argument method as (srid, type) but have the 
single-argument method be just (type)? Can the single-arg method be 
overloaded to support both (type) and (srid)?

My line of thought is that (1) we should keep the geometry version of 
the typmod parameters the same order as the create geometrycolumn 
function, (2) we should keep the geography parameters the same order as 
the geometry parameters,but (3) you're right, the magic number is 
painful and avoidable, it makes sense to provide an additional 
convenience option that hides it, but ideally it is *in addition* to the 
other "standard" methods...

Maybe I'm asking for too much?

Chris

Paul Ramsey wrote:
> Trying to think like a user, and taking into account some changes to
> the typmod design. Note that I am doing this for GEOGRAPHY in the
> first place, and GEOMETRY is not on the agenda until PostGIS 2.0.
>
> So, first of all I have collapsed the dimensionality issues into the
> type declarations. So you declare your type as:
>
> POINT
> POINTZ
> POINTZM
> LINESTRINGZ
> ...
>
> And so on. That means that the typmod string signature is "only" two items long:
>
> CREATE TABLE foo (g geography(4326, POINT));
>
> However, for geography this gets further pointless as the initial
> implementation is only going to accept 4326 as an SRID. And even when
> it *does* accept alternates most people will just want to use 4326.
> Also, one of the user targets for geography is geo-newbies, the folks
> coming in with lonlat data and a dream. They shouldn't need to know
> the "magic number", they should just need to be told "use geography,
> go away".
>
> CREATE TABLE foo (g geography(POINT));
>
> So, should SRID be first? last? I'm actually thinking it could be
> either, because I can test the arguments and if the argument is
> numeric it is the srid and if it is letters that's the type. If we
> want a fixed ordering, then I would now go for geography(type, srid).
> I think for geometry, type *and* srid restrictions will be common, but
> for geography, type-only restrictions will be the more frequent case.
>
> P.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>   




More information about the postgis-devel mailing list