[postgis-devel] Versioning and History

[Ragi Y. Burhum]

> 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>
>
>
>  Ragi,
>  >  Hello Regina and thank you so much for joining the conversation. IMHO
> an
> 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
> to
> append _v1 or _v2  or _v3 to my ALL my tables names to get
> >  the  right    results. It just becomes inconvenient for scripts and
> such.
> 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.
>
>
- Ragi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20091208/fe137e99/attachment.html>