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/
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
