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
|
Список | 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 по дате отправления: