[postgis-devel] Typmod: Making my Life Harder

Paragon Corporation lr at pcorp.us
Mon Aug 3 14:18:43 PDT 2009


Paul, Kevin, Chris, Steve, Dave et al,
Sounds like that is what Paul is proposing with his type checking suggestion
except like Kevin mentioned -- we should have two

geography(type which is text)  -- this I grudgingly accept but like Steve I
kind of don't like defaulting (what's wrong with newbies learning about
magic numbers?)
geography(srid which is integer) 
geography(type, srid)

(not srid,type -- its confusing enough to remember that there is one order
let alone another).  So I'm with Steve and Kevin on this -- NO FLIPFLOPPING.
I don't care if Perl allows you to write the same thing 20 different ways --
this ain't Perl.

and avoid messy type casting if we can though maybe that is not possible
with type mod.  

I guess perhaps I overreacted too much.  Sorry about that.  I'll try to
shutup now.

Thanks,
Regina





-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Chris
Hodgson
Sent: Monday, August 03, 2009 4:39 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Typmod: Making my Life Harder

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
>   

_______________________________________________
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