Joshua D. Drake wrote:
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.
Well, I certainly don't think a setof <name, type> is adequate for
pg_get_tabledef(). What about constraints? And what you are suggesting
can probably be got by very simple queries against either the catalog or
the information schema, and seems to me to have little value.
As for whether or not it belongs in the backend, I don't have strong
feelings - maybe we could add what I'm suggesting as some \ commands in
psql - that would certainly be adequate for the purpose I had in mind,
but might not suit users of higher end design tools.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
