From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | tushar <tushar(dot)ahuja(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Create language syntax is not proper in pg_dumpall and not working using pg_upgrade |
Date: | 2017-07-25 17:06:54 |
Message-ID: | 31582.1501002414@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Jul 25, 2017 at 10:31 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> pg_dump doesn't really support that scenario, and I don't feel any
>> great need to make it do so. Per the comment in dumpProcLang:
> Is this assumption, like, documented someplace?
Uh, right there?
> I would be on board with the idea that you (or anyone, really) doesn't
> want to fix this because it's a fairly unimportant issue, but I balk
> at the notion that nothing is wrong here, because to me that looks
> busted.
Well, it's not just unimportant but smack in the middle of code that
is treading a very narrow path to avoid assorted version dependencies.
I don't want to risk breaking cases that are actually important in the
field to support something that's obviously a toy test case.
We might be able to make some simplification/rationalization here
whenever we desupport pg_dump from < 8.1 servers (ie pre pg_pltemplate).
But right now I'm afraid to touch it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-07-25 17:10:11 | Re: Create language syntax is not proper in pg_dumpall and not working using pg_upgrade |
Previous Message | Tomas Vondra | 2017-07-25 17:02:28 | Re: VACUUM and ANALYZE disagreeing on what reltuples means |