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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_dump throwing "column number -1 is out of range 0..36" on HEAD
Дата
Msg-id 7594.1558549061@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_dump throwing "column number -1 is out of range 0..36" on HEAD  (Andres Freund <andres@anarazel.de>)
Ответы Re: pg_dump throwing "column number -1 is out of range 0..36" on HEAD  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> Wouldn't the better fix be to change
>         if (PQgetisnull(res, i, i_amname))
>             tblinfo[i].amname = NULL;
> into
>         if (i_amname == -1 || PQgetisnull(res, i, i_amname))
>             tblinfo[i].amname = NULL;
> it's much more scalable than adding useless columns everywhere, and we
> already use that approach with i_checkoption (and at a number of other
> places).

FWIW, I think that's a pretty awful idea, and the fact that some
people have had it before doesn't make it less awful.  It's giving
up the ability to detect errors-of-omission, which might easily
be harmful rather than harmless errors.

It does seem like we're overdue to rethink how pg_dump handles
cross-version query differences ... but inconsistently lobotomizing
its internal error detection is not a good start on that.

>> Looks like the right fix.  I'm sad that the buildfarm did not catch
>> this ... why wouldn't the cross-version-upgrade tests have seen it?

> I suspect we just didn't notice that it saw that:
> as it's just a notice, not a failure.

Hm.  But shouldn't we have gotten garbage output from the pg_dump run?

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Teach pg_upgrade test to honor NO_TEMP_INSTALL
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Teach pg_upgrade test to honor NO_TEMP_INSTALL