[postgis-devel] history management

George Silva georger.silva at gmail.com
Thu Feb 25 10:09:27 PST 2010


Also, can you provide the schema for "cases" table and the command you are
using?

On Thu, Feb 25, 2010 at 3:08 PM, George Silva <georger.silva at gmail.com>wrote:

> Of course I'm interested!
>
> I'll look into it. What version are you using? The one shipped with PostGIS
> 1.5?
>
> Your idea is really useful and a situation i did not foresee. It may be
> wise to have a prefix on every field created.
>
> About the view: unless the user is building a more complicated view, the
> table is ready for GIS visualization - and this has a evil side: the user
> can edit it. Perhaps it would be wise to publish just a simple view (even
> with a underlying table) and updating the geometry_columns for that view
> only.
>
> George
>
>
> On Thu, Feb 25, 2010 at 3:03 PM, strk <strk at keybit.net> wrote:
>
>> On Thu, Feb 25, 2010 at 02:39:22PM -0300, George Silva wrote:
>> > Actually it could work in simple tables, but when you are registering
>> > history_tables the system updates geometry_columns.
>> >
>> > I guess that's the only constraint.
>>
>> And I see it enforces no srid or geometrytype check, which seems useful
>> to me I've to say. I'd also drop the messing of geometry_columns as
>> the user can always repopulate it later (and hopefuly will be eventually
>> turned into a view).
>>
>> One thing I see is that the _history table is created with *all* fields
>> from the original table (using "like <orig>" construct). Wouldn't this
>> fail if any field in the original table has the same name of one of
>> the "management" fields ? Would it be hard to "escape" the names
>> so they have a forced prefix or something to avoid the clash ?
>>
>> > The proposed version also has functions to turn off "logging", but for
>> what
>> > i can remember, it doesn't mess with geometry_columns. It's just the
>> > registry process that involves a geometry.
>>
>> I'm not sure I can follow here. I guess I'll make some tests and see
>> what happen. If you're interested, a first naive test following
>> instructions in the README resulted in this:
>>
>> NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index
>> "cases_history_pk" for table "cases_history"
>> CONTEXT:  SQL statement "CREATE TABLE public.cases_history(history_id
>> serial not null,date_added timestamp not null default now(),date_deleted
>> timestamp default null,last_operation varchar(30) not null,active_user
>> varchar(90) not null default CURRENT_USER,current_version text not null,like
>> public.cases,CONSTRAINT cases_history_pk primary key(history_id));"
>> PL/pgSQL function "postgis_enable_history" line 66 at EXECUTE statement
>> ERROR:  cannot EXECUTE a null querystring
>> CONTEXT:  PL/pgSQL function "postgis_enable_history" line 67 at EXECUTE
>> statement
>>
>> --strk;
>>
>>  ()   Free GIS & Flash consultant/developer
>>  /\   http://foo.keybit.net/~strk/services.html<http://foo.keybit.net/%7Estrk/services.html>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>
>
>
> --
> George R. C. Silva
>
> Desenvolvimento em GIS
> http://blog.geoprocessamento.net
> (34) 9664-3717
> (34) 8843-3717
>



-- 
George R. C. Silva

Desenvolvimento em GIS
http://blog.geoprocessamento.net
(34) 9664-3717
(34) 8843-3717
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20100225/a15b2422/attachment.html>


More information about the postgis-devel mailing list