On Mon, Jun 12, 2006 at 08:49:00AM -0400, Andrew Dunstan wrote:
> 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.
I would argue that any case you come up with for why pg_dump shouldn't
use them is most likely going to be an issue for people using these
functions as well, so the functions should handle both. In this case, it
would mean adding a 'without_constraints' option to pg_get_tabledef, and
then the appropriate pg_get_tableconstaintdef() functions.
The only reason I've been able to think of for why pg_dump wouldn't use
a *back end* function for this is because it would then be limited to
dumping in the format provided by that backend, which could become an
issue when upgrading. If that is in fact a problem, it might be useful
to break the code that pg_dump uses for generating DDL into it's own
library that others could include. But even if that is done, I still
feel that these functions should be added to the backend.
Actually, putting the functionality into a library that's used by both
pg_dump and these functions probably makes the most sense. The library
would have to handle multiple server versions, but the functions would
just pass in the current server version.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
