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

Hi,

On 2019-05-24 08:32:29 +0900, Michael Paquier wrote:
> On Thu, May 23, 2019 at 03:31:30PM -0700, Andres Freund wrote:
> > 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.
> 
> Well, I can see why the current solution is not perfect, but we have
> been doing that for some time now, and redesigning that part has a
> much larger impact than a single column.  I have committed the initial
> fix now.

That argument would hold some sway if we there weren't a number of cases
doing it differently in the tree already:

        if (i_checkoption == -1 || PQgetisnull(res, i, i_checkoption))
            tblinfo[i].checkoption = NULL;
        else
            tblinfo[i].checkoption = pg_strdup(PQgetvalue(res, i, i_checkoption));

    if (PQfnumber(res, "protrftypes") != -1)
        protrftypes = PQgetvalue(res, 0, PQfnumber(res, "protrftypes"));
    else
        protrftypes = NULL;

    if (PQfnumber(res, "proparallel") != -1)
        proparallel = PQgetvalue(res, 0, PQfnumber(res, "proparallel"));
    else
        proparallel = NULL;

    if (i_proparallel != -1)
        proparallel = PQgetvalue(res, 0, PQfnumber(res, "proparallel"));
    else
        proparallel = NULL;

And no, I don't buy the consistency argument. Continuing to do redundant
work just because we always have, isn't better than having one useful
and one redundant approach. And yes, a full blown redesign would be
better, but that doesn't get harder by having the -1 checks.

- Andres