Re: Pass ParseState as down to utility functions.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: jian he <jian(dot)universality(at)gmail(dot)com>
Cc: Kirill Reshke <reshkekirill(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Pass ParseState as down to utility functions.
Date: 2024-12-11 20:48:57
Message-ID: 522795.1733950137@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

jian he <jian(dot)universality(at)gmail(dot)com> writes:
> add parser_errposition to some places in
> transformTableConstraint, transformColumnDefinition
> where v8 didn't.

I'm not loving the idea of cons'ing up ParseStates in random places in
tablecmds.c. I think we ought to fix things so that the one made in
standard_ProcessUtility is passed down to all these places, replacing
ad-hoc queryString and queryEnv parameters.

Eventually we might want to make ProcessUtility's callers pass down
a pstate, but that would be a whole other area of invasive changes,
so I think we should leave that idea for later. Right now though,
it seems reasonable to change AlterTableUtilityContext to replace
the queryString and queryEnv fields with a ParseState carrying that
info --- and, perhaps, someday saving us from adding more ad-hoc
fields there.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2024-12-11 20:51:43 Re: proposal: schema variables
Previous Message Guillaume Lelarge 2024-12-11 20:46:16 Re: Proposals for EXPLAIN: rename ANALYZE to EXECUTE and extend VERBOSE