Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR)

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: buildfarm(at)sraoss(dot)co(dot)jp, Andrew Dunstan <andrew(at)dunslane(dot)net>, Christoph Berg <myon(at)debian(dot)org>, Michael Banck <mbanck(at)gmx(dot)net>, Tommy Pavlicek <tommypav122(at)gmail(dot)com>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org, jian(dot)universality(at)gmail(dot)com
Subject: Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR)
Date: 2024-10-27 17:56:59
Message-ID: CAFj8pRBaQeZ50Ub2SKezy1gKqp4cGnkfVo1rV1Rqd=wg-yXAvA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

ne 27. 10. 2024 v 18:42 odesílatel Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> napsal:

> 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.
>

+1

This is very useful feature

Pavel

> regards, tom lane
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2024-10-27 17:58:59 Re: msvc directory missing in PostgreSQL 17.0
Previous Message Tomas Vondra 2024-10-27 17:47:10 libedit history seems to be misbehaving / broken