Re: TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),

> 
> Well, the argument against changing pg_dump is that it would impact the
> ability to use the newer version of pg_dump with older backends (which
> would be lacking these functions).
> 
> ISTM what would be best is to add the functions to the backend, and add
> a TODO or comments to pg_dump indicating that it should be changed to
> use these functions once 8.1 is no longer supported. Or you could make
> pg_dump's use of this code dependent on the server version it connected
> to.

Off list I was speaking with AndrewD and he said that he would expect 
that if we called pg_get_tabledef() it should return the CREATE 
statement for the table.

With all due respect to Andrew, why? At least in my mind these functions 
really belong to app developers.. e.g;

CREATE TABLE foo (id serial);

SELECT pg_get_tabledef(foo) would return

id, serial

Not:

CREATE TABLE foo (id serial);

I mean, I can do either but I would like to get a clear definition of 
what we are looking for here. Maybe:

pg_get_tabledef is the actual SQL and pg_get_tabledesc() is the column, 
datatype output?

I guess I don't see the advantage of putting pg_dump -s -t in the backend.

Joshua D. Drake


-- 
            === The PostgreSQL Company: Command Prompt, Inc. ===      Sales/Support: +1.503.667.4564 || 24x7/Emergency:
+1.800.492.2240     Providing the most comprehensive  PostgreSQL solutions since 1997
http://www.commandprompt.com/