Re: pg_dump new feature: exporting functions only. Bad or good idea ?
| От | Tomas Vondra |
|---|---|
| Тема | Re: pg_dump new feature: exporting functions only. Bad or good idea ? |
| Дата | |
| Msg-id | 269300d1-24c9-5bf2-9fad-812f89ed0091@enterprisedb.com обсуждение исходный текст |
| Ответ на | Re: pg_dump new feature: exporting functions only. Bad or good idea ? (ahsan hadi <ahsan.hadi@gmail.com>) |
| Ответы |
Re: pg_dump new feature: exporting functions only. Bad or good idea ?
|
| Список | pgsql-hackers |
Hi, I took a quick look at the patch today. There was some minor bitrot requiring a rebase, so I attach the rebased patch as v3. The separate 0002 part contains some minor fixes - a couple typos/rewording in the docs (would be good if a native speaker looked at it, thought), and a slightly reworked chunk of code from pg_dump.c. The change is more a matter of personal preference than correctness - it just seems simpler this way, but ymmv. And I disliked that the comment said "If we have to export only the functions .." but the if condition was actually the exact opposite of that. The main question I have is whether this should include procedures. I'd probably argue procedures should be considered different from functions (i.e. requiring a separate --procedures-only option), because it pretty much is meant to be a separate object type. We don't allow calling DROP FUNCTION on a procedure, etc. It'd be silly to introduce an unnecessary ambiguity in pg_dump and have to deal with it sometime later. I wonder if we should allow naming a function to dump, similarly to how --table works for tables, for example. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Вложения
В списке pgsql-hackers по дате отправления: