Re: Extended Statistics set/restore/clear functions. - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Extended Statistics set/restore/clear functions.
Date
Msg-id aTIzH-2Spb4H6BNP@paquier.xyz
Whole thread Raw
In response to Re: Extended Statistics set/restore/clear functions.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Extended Statistics set/restore/clear functions.
List pgsql-hackers
On Thu, Dec 04, 2025 at 07:37:32PM -0500, Tom Lane wrote:
> This of course arises because the source code is passing the address
> of a local ErrorSaveContext variable to that macro.  We don't have
> any other instances of that coding pattern AFAICS, so I wonder if
> that was really the most adapted way to do it.  Looking at the
> code, it seems to be turning around and stuffing a different error
> message into a passed-in ErrorSaveContext, which feels a little
> weird.

Thanks for the report.  Right.  There are three instances of that in
pg_dependencies.c, two in pg_ndistinct.c.  I would not mind doing the
attached to calm down these warnings, matching with the other areas of
the code, that simply removes the macro and checks the state value
directly.

> Also, I don't think these errdetail messages meet our style
> guidelines:
>
>    errdetail("Invalid \"%s\" value.", PG_DEPENDENCIES_KEY_ATTRIBUTES));
>
> They're supposed to be complete sentences.

Yeah, I should have been more careful here.  I have spent more time on
all of these, and adjusted all the errdetails for pg_ndistinct.c and
pg_dependencies.c to use full sentences.

I am just grouping everything with the attached.  They'd be better
if handled separately, obviously.  Comments?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Extended Statistics set/restore/clear functions.
Next
From: Thomas Munro
Date:
Subject: Re: Safer hash table initialization macro