>
> 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/