On Wednesday, August 29, 2012 06:02:24 PM Tom Lane wrote: > Andres Freund <and...@2ndquadrant.com> writes: > > On Wednesday, August 29, 2012 04:44:14 PM Willy-Bas Loos wrote: > >> pg_dump -s should use add_geometrycolumn(...) instead of creating a > >> column+constraints with normal DDL > >> Because, when you don't dump the data, then the record in > >> geometry_columns is lost. > > > > That shouldn't be a problem with postgres 2 anymore as far as I > > understand things? > > The big picture here is that pg_dump doesn't, and is not likely ever to, > know about anything as extension-specific as add_geometrycolumn(). > Rather, if postgis needs some info in a special table geometry_columns, > that should be handled by pg_dump dumping and restoring that table too > (since, again, there is no reason for pg_dump to treat such a table > specially). > > Willy hasn't provided enough context for us to know why that approach > might not be working for him, though a first guess is that he tried to > do a selective dump excluding geometry_columns. > > I believe there was some discussion awhile back about whether postgis > could dodge this problem by cramming its additional info into type > modifiers (with the geometry-type typmodin and typmodout functions > becoming responsible for accessing the special table). I don't know > if that can fly on syntax grounds, but if it can, I think all the core > infrastructure for it is in place as of 9.1. As far as I know, and thats what I tried to refer to, that's done as of postgis 2.0.
Yep: "PostgreSQL typmod integration, for an automagical geometry_columns table" Greetings, Andres -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
