On Wednesday, August 29, 2012 06:02:24 PM Tom Lane wrote:
> Andres Freund <andres@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
