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
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
Naz Gassiep [EMAIL PROTECTED] writes:
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?
Refactoring pg_dump into some sort of library
I think using pg_dump in some cases is a good option , but not all the
time, having a function makes it much cleaner to use
Consider pgAdmin lets say (and there are many such applications out
there) , you need to show object DDL on the RHP and its nicely
formatted and you can copy paste it
When you say pgdump library, do you mean taking all catalog querying
functionality into a contrib like module , exposed as functions and
then have a simple pgdump executable which calls those functions to dump
to a file, because you would still need a pgdump executable i suppose
for people to
I mean as a shared library - a .so for Unix (or whatever the flavor of
unix uses instead) or a DLL on WIndows. And no, it would not be in
contrib - as I mentioned in another thread yesterday I want to propose
that contrib disappear.
Certainly pg_dump would use the library, and retain all
Got it. Thanks for the clarification , i suppose the way you described
it , it needs to go over libpq for the database interface, not the
HeapTuple / Form_pg_* , way.
I guess the way forward for me would be to crawl back in my corner,
write up a mini - spec of how i intend to implement it
Usama Munir wrote:
Got it. Thanks for the clarification , i suppose the way you described
it , it needs to go over libpq for the database interface, not the
HeapTuple / Form_pg_* , way.
Yes, for many reasons including those mentioned in Tom's email on this
subject today.
cheers
Usama Munir wrote:
I think using pg_dump in some cases is a good option , but not all the
time, having a function makes it much cleaner to use
That's why having a shared pgdump library as has been previously
mentioned is by far the best solution.
We have discussed this before, and
Usama Munir [EMAIL PROTECTED] writes:
I guess the way forward for me would be to crawl back in my corner,
write up a mini - spec of how i intend to implement it and get back to
you guys.
Well, the *first* thing to do is read pg_dump for awhile. Until you've
grokked what it does to support
Hi Usama,
On May 21, 2007, at 9:20 AM, Usama Munir wrote:
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
11 matches
Mail list logo