[postgis-devel] Versioning and History
Ragi Y. Burhum
ragi at burhum.com
Tue Dec 8 09:10:16 PST 2009
> Date: Sun, 6 Dec 2009 05:10:41 -0500
> From: "Paragon Corporation" <lr at pcorp.us>
> Subject: Re: [postgis-devel] Versioning and Historyu
> To: "'PostGIS Development Discussion'"
> <postgis-devel at postgis.refractions.net>
> > Hello Regina and thank you so much for joining the conversation. IMHO
> application that will not execute edits on an updatable view is an
> > application with a bug :)
> > However, you do have a valid point.
> > Changing the logic of application to be able to edit rows that don't have
> primary keys is probably a crazy request so I will not go there (I am
> thinking how all the rows in OGR, for example, require an ObjectID).
> Well its kind of questionable where the bug lies. The ideal place to fix
> said bug is in PostgreSQL. If PostgreSQL had some mechanism in creating a
> view to denote what the primary key SHOULD be.
Pushing it lower it is even better. I definitely agree with this.
> Or less desirable for the application (such as what MapServer has -- to
> allow the user to dictate what the primary key is)
Another possibility. I like the other approach better for various reasons.
> > Think about the alternative of *not* using views. I would always have
> append _v1 or _v2 or _v3 to my ALL my tables names to get
> > the right results. It just becomes inconvenient for scripts and
> An that is the scenario where we are talking about workspace-level
> > versioning. If we are talking tables, ugh, I don't even want think about
> it - it would be horrible.
> But I agree with you leveraging views or inherited tables with rules is
> probably the best bet.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the postgis-devel