On Wed, Aug 29, 2012 at 5:46 PM, Andres Freund <andres@xxxxxxxxxxxxxxx> wrote:
Two things:
* the geometry_columns table is not a table anymore but a view of the postgres
catalogs
Great! I didn't know that yet. It must derive the info from the constraints then.
So that means you can just create the column with standard DDL, and there is no more redundant info. Nice :)
So that means you can just create the column with standard DDL, and there is no more redundant info. Nice :)
* extensions (9.1+, used by postgis 2 onwards) can declare configuration
tables now, so even if you would still need a configuration table it would get
dumped in a schema only dump
That's really cool, advanced stuff. It's interesting that the functions still reside in public, but people probably did spend a few thoughts on that.
(why not a separate catalog with all the functions and types etc? hmz maybe because you'd need to change the search_path, which is in postgresql.conf)
I'll look into the typemod stuff further.
(why not a separate catalog with all the functions and types etc? hmz maybe because you'd need to change the search_path, which is in postgresql.conf)
I'll look into the typemod stuff further.
On Wed, Aug 29, 2012 at 6:02 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
>if postgis needs some info in a special table geometry_columns,
>that should be handled by pg_dump dumping and restoring that table too
Well, pg_dump -s doesn't dump the data, so it would then be missing. But it is actually not data, but functional configuration. That's why creating config tables for extensions (that do get dumped with a schema dump) is awesome stuff! (even if postgis doesn't even use it now)
Thanks for your answers.
Cheers,
WBL
--
"Quality comes from focus and clarity of purpose" -- Mark Shuttleworth
