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
