Just a question, is there any advantage to having this then building a
function in applications that wrap and use pg_dump with a few options?
Surely that's a more appropriate way to achieve this functionality?
- Naz.
Usama Munir wrote:
> Hi,
>
> i was following a thread some time ago where adding a function
> *pg_get_tabledef* was one of the TODOs for 8.2, but it somehow didn't
> make it to the release perhaps because the functionality was not
> clearly defined? not sure.
>
> Anyway i happen to come up with a function for pg_get_tabledef which
> works something like following
>
> /postgres=# select pg_get_tabledef(16388) ;
> pg_get_tabledef
> --------------------------------
> CREATE TABLE public.dept
> (
> deptno numeric(2,0) NOT NULL,
> dname character varying(14),
> loc character varying(13)
> )
> WITHOUT OIDS;
> /(1 row)
>
>
>
> i wanted to submit a patch for this, IFF the community wants this
> function. The rationale is obviously to help Application developers
> writing applications like pgAdmin. Currently this part of SQL needs to
> be constructed manually for postgres by the tools.
>
> it is arguable that a table defintion will have constraints , triggers
> etc as well, and they can be added without much problem, but i think
> if a tool needs to construct an SQL for all table related objects then
> functions are already available for them like pg_get_constraintdef,
> pg_get_ruledef, pg_get_indexdef, pg_get_triggerdef etc
>
> i understand that you guys don't like someone to develop a patch in
> isolation and just come up with it one day, but it really came out as
> a by-product of some other work , and i thought you guys might be
> interested in it.
>
> if it is desired, i will submit a patch for it, within a day or so.
>
> Regards,
> Usama Munir
> EnterpriseDB (www.enterprisedb.com)
>
>
>