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

From Andres Freund
Subject Re: pg_dump throwing "column number -1 is out of range 0..36" on HEAD
Date
Msg-id 20190523223130.4b3omu4ykwy5sg4d@alap3.anarazel.de
Whole thread Raw
In response to Re: pg_dump throwing "column number -1 is out of range 0..36" on HEAD  (Michael Paquier <michael@paquier.xyz>)
Responses Re: pg_dump throwing "column number -1 is out of range 0..36" on HEAD
List 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@anarazel.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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: ClosePipeStream failure ignored in pg_import_system_collations
Next
From: Tom Lane
Date:
Subject: Re: Top-N sorts in EXPLAIN, row count estimates, and parallelism