From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Chapman Flack <chap(at)anastigmatix(dot)net> |
Cc: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: SPI/backend equivalent of extended-query Describe(statement)? |
Date: | 2018-05-26 00:55:48 |
Message-ID: | 24186.1527296148@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Chapman Flack <chap(at)anastigmatix(dot)net> writes:
> On 05/25/18 20:07, Andrew Gierth wrote:
>> /*
>> * GAH. To do parameter type checking properly, we have to install our
>> * own global post-parse hook transiently.
>> */
>> ...
>> PG_TRY();
>> {
>> pllua_spi_prev_parse_hook = post_parse_analyze_hook;
>> post_parse_analyze_hook = pllua_spi_prepare_checkparam_hook;
>> ...
>> PG_CATCH();
>> {
>> post_parse_analyze_hook = pllua_spi_prev_parse_hook;
>> --pllua_spi_prepare_recursion;
>> PG_RE_THROW();
>> ...
> Gah, indeed. Thanks for the heads up. I would never have guessed it'd
> be that fiddly.
Yikes. That seems pretty unsafe :-(
Obviously, I missed a bet by not folding check_variable_parameters
into the pstate hook mechanism. It's a bit late to do anything
about that for v11, but I'd favor trying to improve the situation
in v12.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Gierth | 2018-05-26 01:16:04 | Re: SPI/backend equivalent of extended-query Describe(statement)? |
Previous Message | Chapman Flack | 2018-05-26 00:34:42 | Re: SPI/backend equivalent of extended-query Describe(statement)? |