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

From: "Andrew Dunstan" <andrew(at)dunslane(dot)net>
To: <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <jd(at)commandprompt(dot)com>, <pgman(at)candle(dot)pha(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),
Date: 2006-06-11 01:30:54
Message-ID: 3774.24.211.165.134.1149989454.squirrel@www.dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane said:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
>> O.k. so now what I am getting from this thread is, the functions exist
>> now in pg_dump but we want to pull them out of pg_dump and push them
>> into the backend?
>
> That's exactly what I *don't* want to do. If you can think of a
> use-case for these functions outside of pg_dump, feel free to put them
> in the backend, but pg_dump should continue to do things as it does
> now.
>

ISTR we debated this some time ago and decided that it wasn't a good idea
for pg_dump. I certainly agree with Tom about it.

But I think there is almost certainly a good use case for these apart from
pg_dump. I recall many years ago using IBMs QMF facility that would provide
skeleton select for a table, and maybe it gave a create query too (it was
about 20 years ago, so my memory is not perfect). I have sometimes wished we
had such a thing for use in C&P query construction.

cheers

andrew

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2006-06-11 01:47:52 Re: TODO: Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(),
Previous Message Michael Glaesemann 2006-06-11 01:18:11 Re: Ranges for well-ordered types