Re: PostGIS dropgeometrycolumn function (Was: Re: [7.4] - Mailing list pgsql-hackers

From Paul Ramsey
Subject Re: PostGIS dropgeometrycolumn function (Was: Re: [7.4]
Date
Msg-id 13173ADF-567D-11D8-B42D-000393D33C2E@refractions.net
Whole thread Raw
In response to Re: PostGIS dropgeometrycolumn function (Was: Re: [7.4] "permissions problem" with pl/pgsql function )  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PostGIS dropgeometrycolumn function (Was: Re: [7.4] "permissions problem" with pl/pgsql function )  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Bitter experience... I am going to cc Dave here, because I could swear 
we went through many conniptions trying to make this work.

And yet I just did this:

create view mytables as select relname from pg_class where relam = 0 
and relname not like 'pg_%';

And it seems to work fine.

Oh, now I remember. The deal was not views, it was triggers. Since our 
geometry_columns contains some information not available via a query on 
existing data, a trigger was what we wanted, so we could harvest the 
information from a variety of places, and have some spare columns for 
things like the geometry selectivity stats.

Paul

On Tuesday, February 3, 2004, at 11:00 AM, Tom Lane wrote:

> Paul Ramsey <pramsey@refractions.net> writes:
>> In an idea world though, we would construct the thing as a view, so
>> that when you did a CREATE TABLE that included a geometry type, you
>> would automatically get a row in geometry_columns. That requires a 
>> view
>> on system tables though, and that just does not work. :/
>
> Uh, what makes you say it doesn't work?
>
>             regards, tom lane
>     Paul Ramsey     Refractions Research     Email: pramsey@refractions.net     Phone: (250) 885-0632



pgsql-hackers by date:

Previous
From: Rod Taylor
Date:
Subject: Re: Idea about better configuration options for sort
Next
From: "Nicolai Tufar"
Date:
Subject: Turkish Locale in Identifiers (contd.)