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

On Mon, Jun 12, 2006 at 03:47:13PM +1200, Mark Kirkwood wrote:
> Joshua D. Drake wrote:
> >Tom Lane wrote:
> >>"Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
> >>>Trying to get back on point. What is the scope of work for the TODO
> >>>item? Forget everything else I brought up. What is the goal of the
> >>>existing TODO?
> >>
> >>I'm not sure that the TODO item has a reason to live at all, but surely
> >>the first item of work for it should be to figure out what its use-case
> >>is. If pg_dump isn't going to use these functions, what will?
> >
> >Well I can't think of a reason to use the functions as a way to deliver
> >CREATE statements.
> >
> >Anyone else have thoughts?
>
> Keeping 'em separate makes sense to me:
>
> 1/ API (or info schema views) provides the required data (e.g column
> details for a table).
> 2/ client (e.g. pg_dump) decides what to do with it (e.g. construct a
> CREATE statement from the column details).

Which means that every other client that wants to generate DDL
statements has to go through a lot of work to get it right. And then
they have to maintain it for every version of PostgreSQL.

I think it makes a heck of a lot more sense to have a backend function
to do this.

Here's the relevant thread:
http://archives.postgresql.org/pgsql-hackers/2005-12/msg00756.php

The intention is to flesh out the existing pg_get_blahdef functions,
such as pg_get_viewdef(). This clearly means that the functions should
output a complete CREATE command.

One thing that I think should be clarified... why wouldn't pg_dump be
able to use these functions? Is it because of version compatability?

Also (and I'm not pointing fingers at Bruce here), this is yet another
case where if we had a TODO system that actually captured the relevant
information, we all would have saved a bunch of time here debating how
these functions should work. I really hope there will be a discussion
about this at the anniversary.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461