Re: TODO: Add pg_get_acldef(), pg_get_typedefault(),
От | Andrew Dunstan |
---|---|
Тема | Re: TODO: Add pg_get_acldef(), pg_get_typedefault(), |
Дата | |
Msg-id | 448D62BC.6060607@dunslane.net обсуждение исходный текст |
Ответ на | Re: TODO: Add pg_get_acldef(), pg_get_typedefault(), (Mark Kirkwood <markir@paradise.net.nz>) |
Ответы |
Re: TODO: Add pg_get_acldef(), pg_get_typedefault(),
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: