Paul Ramsey <[EMAIL PROTECTED]> writes:
> Oh, now I remember. The deal was not views, it was triggers.
Oh, okay. You're right, we don't do triggers on system tables. But
couldn't you combine a view on the system tables with storage of
additional data outside?
regards, to
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 rem
Paul Ramsey <[EMAIL PROTECTED]> 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 d
One of the great annoyances of the OpenGIS spec is the requirement for
a "geometry_columns" table, that has a list of all the spatial columns
and a little bit of metadata on them (what type are they, what is the
spatial reference system of their coordinates, what is their
dimensionality).
Unfo
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> So, if we replace that with:
> ALTER TABLE table_name ALTER column_name DROP NOT NULL; ?
> should be good to go? still not as clean as doing the straight DROP
> COLUMN, but its a fast fix ...
Yeah, that's what I'd do until the PostGIS guys can reth
On Tue, 20 Jan 2004, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > On Mon, 19 Jan 2004, Tom Lane wrote:
> >> in particular, what SQL command is it trying to execute when it chokes?
>
> > The function is executing:
>
> > EXECUTE ''update pg_attribute set attnotnull = fals
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Mon, 19 Jan 2004, Tom Lane wrote:
>> in particular, what SQL command is it trying to execute when it chokes?
> The function is executing:
> EXECUTE ''update pg_attribute set attnotnull = false from pg_class where
> pg_att
