Hello
I enhanced DO statement syntax to allowing a parameters. Syntax is
relative simple:
do ([varname] vartype := value, ...) $$ ... $$
It allows to pass a content of psql variables to inline code block to
allows more easy scripting
\set schema 'public'
do(text := :'schema') $$
declare r
Am 04.07.2010 06:11, wrote Tom Lane:
... but is it representative of real-world cases?
regards, tom lane
Hi Tom,
we do run an application in productive use that suffered from a similar effect.
We did not have 100 updates per row, but 10-100 updates per row on
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, ...)
Robert Haas robertmh...@gmail.com writes:
On Sun, Jul 4, 2010 at 12:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I believe that none of the dead row versions can be vacuumed during this
test.
Yep, you seem to be right. The table grows to 802 pages. But why is
it that we can't vacuum them as
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.
I have a report from an user that postgres server gave up REINDEX
commands on the almost-disk-full machine. The disk spaces were
filled with old index segments, that should be replaced with
re-constructed files made by the REINDEX.
In mdunlink(), we truncate the first main fork to zero length
and
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
Hello
I am planning to start to implement median function. I wrote some
array based implementation - it is fast, but I hope, so can be much
faster.
The basic question is method of implementation. It can be implemented
via a) custum aggregate functions or b) executor node.
Adventage of @a
21 matches
Mail list logo
