Re: [HACKERS] Create language syntax is not proper in pg_dumpall andnot working using pg_upgrade - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] Create language syntax is not proper in pg_dumpall andnot working using pg_upgrade
Date
Msg-id 20170725172405.mglxk63x3k7rxlu2@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] Create language syntax is not proper in pg_dumpall andnot working using pg_upgrade  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] Create language syntax is not proper in pg_dumpall andnot working using pg_upgrade
Re: [HACKERS] Create language syntax is not proper in pg_dumpall and not working using pg_upgrade
List pgsql-hackers
On 2017-07-25 13:18:25 -0400, Robert Haas wrote:
> On Tue, Jul 25, 2017 at 1:13 PM, Andres Freund <andres@anarazel.de> wrote:
> > On 2017-07-25 13:10:11 -0400, Robert Haas wrote:
> >> On Tue, Jul 25, 2017 at 1:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> >> Is this assumption, like, documented someplace?
> >> >
> >> > Uh, right there?
> >>
> >> I don't think we can expect end-users to read the code comments to
> >> determine whether their apparently-legal SQL is fully supported.
> >
> > I don't think plain end-users are going to create differently named PLs
> > using builtin handlers. There's plenty special casing of system object
> > in pg_dump and elsewhere. Dependency tracking doesn't quite work right
> > if you refer to system objects either, etc.  This is superuser only
> > stuff, for a reason.
> 
> But superuser != developer.  Superusers aren't obliged to read the
> code comments any more than any other user.

And yet we tell them that they're to blame if they do a CREATE FUNCTION
with the wrong signature, or a DELETE FROM pg_class; or ...


> I think the only reason we don't get people whining about stuff like
> this more than we do is that it's pretty obscure.  But I bet if we
> look through the pgsql-bugs archives we can find people complaining
> about various cases where they did assorted seemingly-legal things
> that turned out not to be supported by pg_dump.  Whether this
> particular thing has been discovered by anyone before, I dunno.  But
> there's certainly a whole category of bug reports along the line of
> "pg_dump works mostly, except when I do X".

Yes, and?  We can try to address countless intentionally unsupported
edge-cases, but it's going to cost code, complexity and time. And very
likely it's going to add hard to find, test and address bugs. pg_dump is
complicated as is, I don't think trying to address every conceivable
weirdness is a good idea. There's plenty more fundamental things wrong
(e.g. DDL concurrent with a dump sometimes breaking that dump).

I'm not sure what you're arguing for here.

- Andres



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] Create language syntax is not proper in pg_dumpall andnot working using pg_upgrade
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Testlib.pm vs msys