Re: pg_dump throwing "column number -1 is out of range 0..36" on HEAD

From: Andres Freund <andres(at)anarazel(dot)de>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: pg_dump throwing "column number -1 is out of range 0..36" on HEAD
Date: 2019-05-23 22:31:30
Message-ID: 20190523223130.4b3omu4ykwy5sg4d@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2019-05-23 09:11:33 +0900, Michael Paquier wrote:
> On Wed, May 22, 2019 at 02:39:54PM -0400, Tom Lane wrote:
> > Andres Freund <andres(at)anarazel(dot)de> writes:
> >> Well, if we explicitly have to check for -1, it's not really an error of
> >> omission for everything. Yes, we could forget returning the amname in a
> >> newer version of the query, but given that we usually just forward copy
> >> the query that's not that likely.
> >
> > No, the concerns I have are about (1) failure to insert the extra return
> > column into all branches where it's needed; (2) some unexpected run-time
> > problem causing the PGresult to not have the expected column.
>
> Using a -1 check is not something I find much helpful, because this
> masks the real problem that some queries may not have the output they
> expect.

I don't buy this, at all. The likelihood of introducing failures by
having to modify a lot of queries nobody runs is much higher than what
we gain by the additional "checks". If this were something on the type
system level, where the compiler would detect the error, even without
running the query: Yea, ok. But it's not.

> Yes. I don't think that this is completely wrong. So, are there any
> objections if I just apply the patch at the top of this thread and fix
> the issue?

Well, I think the approach of duplicating code all over is a bad idea,
and the fix is many times too big. But it's better than not fixing.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-05-23 22:31:43 Re: Top-N sorts in EXPLAIN, row count estimates, and parallelism
Previous Message Tom Lane 2019-05-23 22:27:53 Re: FullTransactionId changes are causing portability issues