On Sat, Jun 10, 2006 at 08:20:15PM -0700, 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.
If all you want is column, datatype, why not just use info_schema, or
newsysviews? Or even the base catalogs?
ISTM what would be of the most value is a way to get the actual DDL you
need to create the table (which includes a heck of a lot more than just
column names and data types).
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
