| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
| Cc: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: TODO: Add pg_get_acldef(), pg_get_typedefault(), |
| Date: | 2006-06-12 16:06:17 |
| Message-ID: | 448D90F9.6030208@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jim C. Nasby wrote:
>
> 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.
>
>
Jim, you referred to previous debate in one of your postings. There has
been previous debate on this issue too.
Before we pull pg_dump to bits let's identify some actual benefit from
doing so. If you look at the code you will see that it is more than
somewhat complex. A large scale move like you are proposing would be
very high risk, IMNSHO.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Cave-Ayland | 2006-06-12 16:13:24 | Re: Proposal for debugging of server-side stored procedures |
| Previous Message | Kris Kennaway | 2006-06-12 15:38:01 | Re: postgresql and process titles |