Thanks, guys!
I'll take a closer look at the information_schema and pgAdmin and
Maestro. Reinventing the wheel isn't a problem as this job is not
critical, but the educational experience in looking at the system from
another POV may be the bigger prize.
- Bill
On 11/17/2011 8:34 PM, David Johnston wrote:
On Nov 17, 2011, at 22:17, Bill Thoen<bth...@gisnet.com> wrote:
I need to assemble a complete data dictionary for project documentation and
other purposes and I was wondering about the pros and cons of using the
pg_catalog metadata. But I hesitate to poke around in here because I don't know
why it's kept so out of sight and not much documented. But it seems like an
ideal source of information to tap with a program to generate accurate, current
reports of what's in the database.
Is this a bad idea (everything I'm thinking of doing would be read only except
for the description fields) but I'd just like to make sure that there's not
some innocent looking table in there that acts as a doomsday device if you so
much as read its first record, etc. I'm just not sure why this isn't more
widely used or talked about.
Regards,
Bill Thoen
GISnet
http://gisnet.com
303-786-9961
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
information_schema is the more standardized point of entry into the database
meta-data, catalog is generally intended for internals use and thus has a less
stable API contract. That said, you are reinventing the wheel if you are
looking for a straight dump of the current reality. Various third-party tools
already do this. I've used, but am not affiliated with, PostgreSQL Maestro.
Also, pgAdmin, I think, provides access to this information as well (as does
psql via it's various commands).
You should never directly update the catalog but instead use the appropriate SQL command.
For descriptions you need to use "COMMENT ON". Reading it should never cause
a problem.
David J.
