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)
>  )
> /(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)

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Reply via email to