Also, can you provide the schema for "cases" table and the command you are using?<br><br><div class="gmail_quote">On Thu, Feb 25, 2010 at 3:08 PM, George Silva <span dir="ltr"><<a href="mailto:georger.silva@gmail.com">georger.silva@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Of course I'm interested!<br><br>I'll look into it. What version are you using? The one shipped with PostGIS 1.5?<br>
<br>Your idea is really useful and a situation i did not foresee. It may be wise to have a prefix on every field created.<br>
<br>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.<br>
<font color="#888888">
<br>George</font><div><div></div><div class="h5"><br><br><div class="gmail_quote">On Thu, Feb 25, 2010 at 3:03 PM, strk <span dir="ltr"><<a href="mailto:strk@keybit.net" target="_blank">strk@keybit.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>On Thu, Feb 25, 2010 at 02:39:22PM -0300, George Silva wrote:<br>
> Actually it could work in simple tables, but when you are registering<br>
> history_tables the system updates geometry_columns.<br>
><br>
> I guess that's the only constraint.<br>
<br>
</div>And I see it enforces no srid or geometrytype check, which seems useful<br>
to me I've to say. I'd also drop the messing of geometry_columns as<br>
the user can always repopulate it later (and hopefuly will be eventually<br>
turned into a view).<br>
<br>
One thing I see is that the _history table is created with *all* fields<br>
from the original table (using "like <orig>" construct). Wouldn't this<br>
fail if any field in the original table has the same name of one of<br>
the "management" fields ? Would it be hard to "escape" the names<br>
so they have a forced prefix or something to avoid the clash ?<br>
<div><br>
> The proposed version also has functions to turn off "logging", but for what<br>
> i can remember, it doesn't mess with geometry_columns. It's just the<br>
> registry process that involves a geometry.<br>
<br>
</div>I'm not sure I can follow here. I guess I'll make some tests and see<br>
what happen. If you're interested, a first naive test following<br>
instructions in the README resulted in this:<br>
<br>
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "cases_history_pk" for table "cases_history"<br>
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));"<br>
PL/pgSQL function "postgis_enable_history" line 66 at EXECUTE statement<br>
ERROR: cannot EXECUTE a null querystring<br>
CONTEXT: PL/pgSQL function "postgis_enable_history" line 67 at EXECUTE statement<br>
<div><div></div><div><br>
--strk;<br>
<br>
() Free GIS & Flash consultant/developer<br>
/\ <a href="http://foo.keybit.net/%7Estrk/services.html" target="_blank">http://foo.keybit.net/~strk/services.html</a><br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@postgis.refractions.net" target="_blank">postgis-devel@postgis.refractions.net</a><br>
<a href="http://postgis.refractions.net/mailman/listinfo/postgis-devel" target="_blank">http://postgis.refractions.net/mailman/listinfo/postgis-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><br></div></div><div><div></div><div class="h5">-- <br>George R. C. Silva<br><br>Desenvolvimento em GIS<br><a href="http://blog.geoprocessamento.net" target="_blank">http://blog.geoprocessamento.net</a><br>
(34) 9664-3717<br>(34) 8843-3717<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>George R. C. Silva<br><br>Desenvolvimento em GIS<br><a href="http://blog.geoprocessamento.net">http://blog.geoprocessamento.net</a><br>(34) 9664-3717<br>(34) 8843-3717<br>