Re: Retail DDL - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Retail DDL
Date
Msg-id 1748518.1753392970@sss.pgh.pa.us
Whole thread Raw
In response to Retail DDL  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Retail DDL
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> .... I have been trying to think 
> of a reasonable interface for a single function, where we would pass in, 
> say, a catalog oid plus an object oid, and maybe some optional extra 
> arguments. That seems a bit fragile, though. The alternative is that we 
> have a separate function for each object type, e.g. 
> pg_get_{objecttype}_ddl. I'm kinda leaning that way, but I'd like some 
> sort of consensus before any work gets done.

I'm good with pg_get_{objecttype}_ddl.  The reason I like it is that
that sets expectations for what the function can do, and we don't
have to immediately cover every object type there is in order to not
have a function with unexpected restrictions.

A small advantage is that, for object types having a reg* pseudotype,
we can declare the function as (say)

    pg_get_table_ddl(regclass)

and that means this will work with no additional decoration:

    select pg_get_table_ddl('mytable');

Nearby, Isaac suggested sort of the reverse of that, where
you'd have to write

    select pg_get_ddl('mytable'::regclass);

but I don't see any great advantages in that --- and it can't scale
to object types that lack a reg* type.

            regards, tom lane



pgsql-hackers by date:

Previous
From: KAZAR Ayoub
Date:
Subject: Re: Experimenting with hash join prefetch
Next
From: Dave Cramer
Date:
Subject: Re: More protocol.h replacements this time into walsender.c