Re: Create language syntax is not proper in pg_dumpall and not working using pg_upgrade

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

In response to

Responses

Browse pgsql-hackers by date

  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