Mark Kirkwood wrote:
Jim C. Nasby wrote:
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.
Ok, good point, if I'm writing some admin or data movement package,
then these guys would be great!
I guess a possible compromise for those who want to keep the core
backend lean is to implement pg_get_blahdef (and friends) in a contrib
module similar to (or part of) the adminpack stuff.
This would mean that pg_dump would *not* use them - but if I've
followed this thread properly, that may be fine.
Yes ... except that I don't see any good reason to have these in a
contrib module and keep, say, pg_get_viewdef() in core. They belong
together, I think, and I don't think they represent so much bloat that
having them in core would be a huge problem. Either way, pg_dump should
not use them, I think. One reason pg_dump should not use them is that
creation might involve several things which it would want to split up
for reasons of efficiency and robustness, e.g. delaying creation of a
constraint until after data is loaded.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
