> "Chapman" == Chapman Flack writes:
>> So what I'm thinking now is that the way to go, if one wants to
>> imitate the client-side protocol behavior closely, would be to have
>> a setup hook that calls parse_variable_parameters the first time,
>> and then parse_fixed_parameters on subsequ
On 05/26/18 15:22, Andrew Gierth wrote:
> So what I'm thinking now is that the way to go, if one wants to imitate
> the client-side protocol behavior closely, would be to have a setup hook
> that calls parse_variable_parameters the first time, and then
> parse_fixed_parameters on subsequent calls f
> "Chapman" == Chapman Flack writes:
>> Really our hook mechanism only supports adding hooks, not removing
>> them.
Chapman> I suppose the pllua_spi_prepare_checkparam_hook could be
Chapman> linked in once and for all, and turned on and off just where
Chapman> the code now hooks and unh
On 05/26/18 10:03, Tom Lane wrote:
> Really our hook mechanism only supports adding hooks, not removing them.
I suppose the pllua_spi_prepare_checkparam_hook could be linked in once
and for all, and turned on and off just where the code now hooks and
unhooks it, and just forward to the next hook w
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> Yikes. That seems pretty unsafe :-(
> I put in a recursion check out of paranoia, but even after considerable
> thought wasn't able to figure out any scenario that would actually break
> it. If it's actually unsafe I'd really like to kno
On 05/25/18 21:16, Andrew Gierth wrote:
>> "Tom" == Tom Lane writes:
> Tom> about that for v11, but I'd favor trying to improve the situation
> Tom> in v12.
>
> Yeah. Another issue I ran into is that if you use SPI_prepare_params,
> then you have to use SPI_execute_plan_with_paramlist, it's
> "Tom" == Tom Lane writes:
>>> /*
>>> * GAH. To do parameter type checking properly, we have to install our
>>> * own global post-parse hook transiently.
>>> */
>> Gah, indeed. Thanks for the heads up. I would never have guessed it'd
>> be that fiddly.
Tom> Yikes. That seems pretty
Chapman Flack 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_h
On 05/25/18 20:07, Andrew Gierth wrote:
> >> with writing a ParserSetupHook that's just a thin wrapper around
> >> parse_variable_parameters ?
>
> That's what I did in pllua-ng. The tricky bit was in arranging to also
> call check_variable_parameters; I considered skipping that part, but
> that
> "Tom" == Tom Lane writes:
> Chapman Flack writes:
>> As for bringing it along to the modern API, am I on the right track
>> with writing a ParserSetupHook that's just a thin wrapper around
>> parse_variable_parameters ?
Tom> Seems reasonable from here.
That's what I did in pllua-ng.
Chapman Flack writes:
> As for bringing it along to the modern API, am I on the right track
> with writing a ParserSetupHook that's just a thin wrapper around
> parse_variable_parameters ?
Seems reasonable from here.
regards, tom lane
On 05/25/2018 06:01 PM, Tom Lane wrote:
> Offhand I don't believe SPI exposed a way to do that before 9bedd128d.
> Does it matter? Pre-9.0 releases are long out of support by now,
> which means they're full of known data-loss hazards and security bugs.
Well, my exploration arose from discovering
Chapman Flack writes:
> Am I on the right track here? Is what I'm looking to do something
> that became possible in SPI in 9.0 and wasn't before, or did I overlook
> a way it could have been done pre-9.0 ?
Offhand I don't believe SPI exposed a way to do that before 9bedd128d.
Does it matter? Pre
On 05/24/2018 02:30 AM, Chapman Flack wrote:
> In 9.0, there's SPI_prepare_params, which seems promising; it accepts
> an arbitrary ParserSetupHook "to control the parsing of external parameter
> references." But its documentation doesn't suggest what to use as the
> ParserSetupHook to say "please
On 05/14/18 13:46, Chapman Flack wrote:
> On 05/14/18 11:29, Tom Lane wrote:
>> Chapman Flack writes:
>>> The longer version of $subject is: how would one go about, in the
>>> backend using SPI (or SPI and maybe other server APIs as needed),
>>> obtaining the same inferred parameter information th
Chapman Flack writes:
> Where should I look to learn more about the capabilities of the type
> inference done in planning?
It's not terribly well documented outside the source code, I fear.
> Not everything-there-is-to-know, but basics
> like, can some simple query constructs reliably cause an i
On 05/14/18 11:29, Tom Lane wrote:
> Chapman Flack writes:
>> The longer version of $subject is: how would one go about, in the
>> backend using SPI (or SPI and maybe other server APIs as needed),
>> obtaining the same inferred parameter information that a front-end
>> client can get with the Desc
2018-05-14 17:29 GMT+02:00 Tom Lane :
> Chapman Flack writes:
> > The longer version of $subject is: how would one go about, in the
> > backend using SPI (or SPI and maybe other server APIs as needed),
> > obtaining the same inferred parameter information that a front-end
> > client can get with
Chapman Flack writes:
> The longer version of $subject is: how would one go about, in the
> backend using SPI (or SPI and maybe other server APIs as needed),
> obtaining the same inferred parameter information that a front-end
> client can get with the Describe (statement variant) extended-query
>
The longer version of $subject is: how would one go about, in the
backend using SPI (or SPI and maybe other server APIs as needed),
obtaining the same inferred parameter information that a front-end
client can get with the Describe (statement variant) extended-query
message?
I ask because I've stu
20 matches
Mail list logo
