Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR)
Date
Msg-id 3792414.1730050914@sss.pgh.pa.us
Whole thread Raw
In response to Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR)
Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR)
List pgsql-hackers
I wrote:
> In the no-good-deed-goes-unpunished department: buildfarm member
> hamerkop doesn't like this patch [1].  The diffs look like
> ...
> So what I'd like to do to fix this is to change
> -    if ((file = AllocateFile(filename, PG_BINARY_R)) == NULL)
> +    if ((file = AllocateFile(filename, "r")) == NULL)

Well, that didn't fix it :-(.  I went so far as to extract the raw log
files from the buildfarm database, and what they show is that there is
absolutely no difference between the lines diff is claiming are
different:

-QUERY:  CREATE FUNCTIN my_erroneous_func(int) RETURNS int LANGUAGE SQL\r\n
+QUERY:  CREATE FUNCTIN my_erroneous_func(int) RETURNS int LANGUAGE SQL\r\n

It's the same both before and after 924e03917, which made the code
change depicted above, so that didn't help.

So I'm pretty baffled.  I suppose the expected and result files must
actually be different, and something in subsequent processing is
losing the difference before it gets to the buildfarm database.
But I don't have the ability to debug that from here.  Does anyone
with access to hamerkop want to poke into this?

Without additional information, the only thing I can think of that
I have any confidence will eliminate these failures is to reformat
the affected test cases so that they produce just a single line of
output.  That's kind of annoying from a functionality-coverage point
of view, but I'm not sure avoiding it is worth moving mountains for.

In any case, I'm disinclined to revert 924e03917.  It seems like a
good change on balance, even if it failed to fix whatever is
happening on hamerkop.

            regards, tom lane



pgsql-hackers by date:

Previous
From: jian he
Date:
Subject: Re: Change COPY ... ON_ERROR ignore to ON_ERROR ignore_row
Next
From: Tomas Vondra
Date:
Subject: libedit history seems to be misbehaving / broken