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
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 som
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 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
On Wed, May 22, 2019 at 02:39:54PM -0400, Tom Lane wrote:
> Andres Freund 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 for
On 5/22/19 9:46 AM, Tom Lane wrote:
> Michael Paquier writes:
>> Trying to do pg_dump[all] on a 9.5 or older server results in spurious
>> failures:
>> pg_dump: column number -1 is out of range 0..36
>> After looking around, the problem comes from
>> check_tuple_field_number(), more specifically
Andres Freund writes:
> On 2019-05-22 14:17:41 -0400, Tom Lane wrote:
>> 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 th
Hi,
On 2019-05-22 14:17:41 -0400, Tom Lane wrote:
> Andres Freund 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))
> >
Andres Freund 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 muc
Hi,
On 2019-05-22 09:46:19 -0400, Tom Lane wrote:
> Michael Paquier writes:
> > Trying to do pg_dump[all] on a 9.5 or older server results in spurious
> > failures:
> > pg_dump: column number -1 is out of range 0..36
>
> > After looking around, the problem comes from
> > check_tuple_field_number
Michael Paquier writes:
> Trying to do pg_dump[all] on a 9.5 or older server results in spurious
> failures:
> pg_dump: column number -1 is out of range 0..36
> After looking around, the problem comes from
> check_tuple_field_number(), more specifically from getTables() where
> someone has forgot
> On Wed, May 22, 2019 at 10:34 AM Michael Paquier wrote:
>
> Trying to do pg_dump[all] on a 9.5 or older server results in spurious
> failures:
> pg_dump: column number -1 is out of range 0..36
>
> After looking around, the problem comes from
> check_tuple_field_number(), more specifically from g
Hi all,
Trying to do pg_dump[all] on a 9.5 or older server results in spurious
failures:
pg_dump: column number -1 is out of range 0..36
After looking around, the problem comes from
check_tuple_field_number(), more specifically from getTables() where
someone has forgotten to add NULL values for a
12 matches
Mail list logo
