Re: Pass ParseState as down to utility functions.

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Kirill Reshke <reshkekirill(at)gmail(dot)com>
Cc: jian he <jian(dot)universality(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Pass ParseState as down to utility functions.
Date: 2024-12-05 06:45:41
Message-ID: Z1FMFTLXTnvUhgOY@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 04, 2024 at 03:31:47PM +0500, Kirill Reshke wrote:
> On Sat, 30 Nov 2024 at 17:37, jian he <jian(dot)universality(at)gmail(dot)com> wrote:
>> So I guess bundling it into a single patch should be fine?
>
> Ok. I created CF entry for this patch.
>
> [0] https://commitfest.postgresql.org/51/5420/

Note that v3 of the patch is failing in the CI, so you should look at
that:
https://cirrus-ci.com/github/postgresql-cfbot/postgresql/cf%2F5420

Combining everything into a single patch is not a big deal in this
case IMO as the code paths touched are different.

I was playing with the patch and tried how typenameType() would like
to force a rule so as the pstate should be always non-NULL, and got
reminded by the various callers of typenameTypeIdAndMod() that this
was a bad idea.

This patch does not show how the error reports are influenced for
DefineType() and AlterType().

This reminds as well that there is little coverage for many error
paths of DefineDomain(), with some paths actually modified in this
patch:
https://coverage.postgresql.org/src/backend/commands/typecmds.c.gcov.html
I'd suggest to do something about that, while on it, to check that the
parser issues a location on error.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2024-12-05 06:51:24 Re: proposal: schema variables
Previous Message Peter Eisentraut 2024-12-05 06:41:55 Re: simplify regular expression locale global variables