Re: proof concept: do statement parametrization

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Florian Pflug <fgp(at)phlo(dot)org>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proof concept: do statement parametrization
Date: 2010-07-04 11:57:27
Message-ID: AANLkTikq81DBYCoAgyumKPee02DhLACLW5275j0M4nVL@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2010/7/4 Florian Pflug <fgp(at)phlo(dot)org>:
> On Jul4, 2010, at 11:59 , Pavel Stehule wrote:
>> 2010/7/4 Florian Pflug <fgp(at)phlo(dot)org>:
>>> On Jul4, 2010, at 08:41 , Pavel Stehule wrote:
>>>> I enhanced DO statement syntax to allowing a parameters. Syntax is
>>>> relative simple:
>>>>
>>>> do ([varname] vartype := value, ...) $$ ... $$
>>>
>>> I think it'd be more useful to put the values at the very end of the statement, not somewhere in the middle. For positional parameters I envision
>>>
>>> do (vartype, ...) $$ ... $$ using value, ...
>>>
>>> and for named parameters it'd be
>>>
>>> do (varname vartype) $$ ... $$ using varname := value, ...
>
>> Your syntax  is longer and less readable (my personal view). With
>> proposed syntax it is ensured so every parameter has a value. Next -
>> my syntax is reflecting fact, so these are not true parameters - it's
>> +/- similar to default values of function parameters.
>
> Yeah, with your syntax omitting a value is syntactically invalid, while with mine it'd parse OK and fail later on. But I fail to see the drawback of that. I do agree that my suggestion is slightly more verbose, but it think thats compensated by the increase in usefulness.
>
>> I understand to your motivation - but you can use a printf command and
>> do it same work.
>
> Sure. But by the very same argument, printf makes DO-block parameters redundant as a whole.
>

printf isn't nice, agree - it is just workaround for some special case
- when you don't store code in variable, then you have not any
problems.

>> or better and safer - use a psql variables (it is preferred solution)
>
> I don't really buy that argument. By using a psql variable, you simply move the quoting & escaping business from SQL to the shell where psql is called. True, you avoid SQL injectiont, but in turn you make yourself vulnerable to shell injection.

can you show some example of shell injection? For me, this way via
psql variables is the best. There are clean interface between outer
and inner space. And I can call simply just psql scripts - without
external bash.

best regards
Pavel

p.s. theoretically do statement can support both syntax, maybe mix of
all. It's only about 20 lines more in parser. But code will be little
bit more complex and I am not sure if it is necessary. I dislike the
space between variable definition and values - and you have to put
param list on the statement end.

>
> best regards,
> Florian Pflug
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-07-04 13:48:38 Re: pessimal trivial-update performance
Previous Message Florian Pflug 2010-07-04 11:36:25 Re: proof concept: do statement parametrization