Re: TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),

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