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
2010/7/4 Florian Pflug f...@phlo.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
On Jul4, 2010, at 11:59 , Pavel Stehule wrote:
2010/7/4 Florian Pflug f...@phlo.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
2010/7/4 Florian Pflug f...@phlo.org:
On Jul4, 2010, at 11:59 , Pavel Stehule wrote:
2010/7/4 Florian Pflug f...@phlo.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, ...)
Pavel Stehule pavel.steh...@gmail.com writes:
my syntax is reflecting fact, so these are not true parameters - it's
+/- similar to default values of function parameters.
FWIW, that doesn't seem like a positive to me.
You cannot to
write do (a int := $1) $$ ... $$ - because utils statements
On Sun, July 4, 2010 9:58 am, Tom Lane wrote:
BTW, we intentionally didn't put any provision for parameters into DO
originally. What's changed to alter that decision?
Nothing that I know of, I think there is just a little impatience here. I
think the consensus was that we needed to get some
2010/7/4 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
my syntax is reflecting fact, so these are not true parameters - it's
+/- similar to default values of function parameters.
FWIW, that doesn't seem like a positive to me.
You cannot to
write do (a int :=
2010/7/4 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
my syntax is reflecting fact, so these are not true parameters - it's
+/- similar to default values of function parameters.
FWIW, that doesn't seem like a positive to me.
You cannot to
write do (a int :=
Pavel Stehule wrote:
BTW, we intentionally didn't put any provision for parameters into DO
originally. What's changed to alter that decision?
It just concept - nothing more. And my instinct speak so inline code
block without external parametrization is useless.
You have said
2010/7/4 Andrew Dunstan and...@dunslane.net:
Pavel Stehule wrote:
BTW, we intentionally didn't put any provision for parameters into DO
originally. What's changed to alter that decision?
It just concept - nothing more. And my instinct speak so inline code
block without external
Andrew Dunstan and...@dunslane.net writes:
This whole proposal strikes me as premature. What we need is some
experience from the field in using DO before we can sensibly decide how
it should be extended. And we won't get that until 9.0 has been released
and used for a while.
+1.
What
On Sun, Jul 04, 2010 at 11:38:47AM -0400, Andrew Dunstan wrote:
Pavel Stehule wrote:
BTW, we intentionally didn't put any provision for parameters into DO
originally. What's changed to alter that decision?
It just concept - nothing more. And my instinct speak so inline code
block
2010/7/4 Tom Lane t...@sss.pgh.pa.us:
Andrew Dunstan and...@dunslane.net writes:
This whole proposal strikes me as premature. What we need is some
experience from the field in using DO before we can sensibly decide how
it should be extended. And we won't get that until 9.0 has been released
2010/7/4 Andres Freund and...@anarazel.de:
On Sun, Jul 04, 2010 at 11:38:47AM -0400, Andrew Dunstan wrote:
Pavel Stehule wrote:
BTW, we intentionally didn't put any provision for parameters into DO
originally. What's changed to alter that decision?
It just concept - nothing more. And
On Jul4, 2010, at 13:57 , Pavel Stehule wrote:
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.
2010/7/5 Florian Pflug f...@phlo.org:
On Jul4, 2010, at 13:57 , Pavel Stehule wrote:
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
16 matches
Mail list logo
