On 1/14/14, 6:15 PM, Tom Lane wrote:
We don't actually implement this in PG yet, except for trivial cases, but
it will certainly happen eventually. I think your sketch above deviates
unnecessarily from what the standard says for UPDATE. In particular
I think it'd be better to write things like
On 1/15/14, 12:35 AM, Tom Lane wrote:
Jim Nasby j...@nasby.net writes:
Do we actually support = right now? We already support
v_field := field FROM table ... ;
and I think it's a bad idea to have different meaning for = and :=.
That ship sailed a *very* long time ago. See other thread about
On Wed, Jan 15, 2014 at 8:23 AM, Jim Nasby j...@nasby.net wrote:
Do we actually support = right now? We already support
v_field := field FROM table ... ;
and I think it's a bad idea to have different meaning for = and :=.
That was already discussed before. Yes, we support both = and := and
2014/1/15 Jim Nasby j...@nasby.net
On 1/14/14, 11:15 AM, Tom Lane wrote:
How about:
(a) = SELECT 1;
(a, b) = SELECT 1, 2;
(a, b) = INSERT INTO foo RETURNING col1, col2;
Same semantics: TOO_MANY_ROWS on rows 1, sets FOUND and row_count.
AFAICT this can be parsed unambiguously,
I am thinking so GUC and plpgsql option can live together. If you like to
accent a some behave, then you can use a plpgsql option. On second hand, I
would to use a some functionality, that is safe, but I don't would to dirty
source code by using repeated options. But I have to check (and
2014/1/14 Florian Pflug f...@phlo.org
On Jan14, 2014, at 00:52 , Marko Tiikkaja ma...@joh.to wrote:
When I've worked with PL/PgSQL, this has been a source of a few bugs that
would have been noticed during testing if the behaviour of INTO wasn't as
dangerous as it is right now.
The
On 1/14/14 10:16 AM, Pavel Stehule wrote:
2014/1/14 Florian Pflug f...@phlo.org
So if we really want to change this, I think we need to have a
LANGUAGE_VERSION attribute on functions. Each time a major postgres release
changes the behaviour of one of the procedural languages, we'd increment
I've always hated INTO in procedures since it makes the code harder to
follow and has very different behavior on the SQL level, in addition
to the multi-row problem you bring up. If we can make assignment
syntax more versatile and eventually replace INTO, then that solves
multiple problems in the
On 1/14/14 12:28 PM, Marti Raudsepp wrote:
I've always hated INTO in procedures since it makes the code harder to
follow and has very different behavior on the SQL level, in addition
to the multi-row problem you bring up. If we can make assignment
syntax more versatile and eventually replace
2014/1/14 Marko Tiikkaja ma...@joh.to
On 1/14/14 12:28 PM, Marti Raudsepp wrote:
I've always hated INTO in procedures since it makes the code harder to
follow and has very different behavior on the SQL level, in addition
to the multi-row problem you bring up. If we can make assignment
On 1/14/14 1:28 PM, Pavel Stehule wrote:
I prefer subquery only syntax - a := (some) or (a,b,c) = (some a,b,c) with
possible enhancing for statements with RETURNING
a advance is compatibility with DB2 (SQL/PSM) syntax - and this code is
written now - it is done in my sql/psm implementation
Hello
2014/1/14 Marko Tiikkaja ma...@joh.to
On 1/14/14 1:28 PM, Pavel Stehule wrote:
I prefer subquery only syntax - a := (some) or (a,b,c) = (some a,b,c) with
possible enhancing for statements with RETURNING
a advance is compatibility with DB2 (SQL/PSM) syntax - and this code is
written
Marko Tiikkaja ma...@joh.to writes:
On 1/14/14 12:28 PM, Marti Raudsepp wrote:
Now, another question is whether it's possible to make the syntax
work. Is this an assignment from the result of a subquery, or is it a
query by itself?
a = (SELECT foo FROM table);
That looks like a scalar
On 1/14/14, 6:15 PM, Tom Lane wrote:
Marko Tiikkaja ma...@joh.to writes:
How about:
(a) = SELECT 1;
(a, b) = SELECT 1, 2;
(a, b) = INSERT INTO foo RETURNING col1, col2;
Same semantics: TOO_MANY_ROWS on rows 1, sets FOUND and row_count.
AFAICT this can be parsed
Marko Tiikkaja ma...@joh.to writes:
On 1/14/14, 6:15 PM, Tom Lane wrote:
I'm not too sure what it'd take to make this work. Right now,
SELECT (SELECT x, y FROM foo WHERE id = 42);
would generate ERROR: subquery must return only one column, but
I think it's mostly a historical artifact
On 1/14/14, 11:15 AM, Tom Lane wrote:
How about:
(a) = SELECT 1;
(a, b) = SELECT 1, 2;
(a, b) = INSERT INTO foo RETURNING col1, col2;
Same semantics: TOO_MANY_ROWS on rows 1, sets FOUND and row_count.
AFAICT this can be parsed unambiguously, too, and we don't need to look
at the
Jim Nasby j...@nasby.net writes:
Do we actually support = right now? We already support
v_field := field FROM table ... ;
and I think it's a bad idea to have different meaning for = and :=.
That ship sailed a *very* long time ago. See other thread about
documenting rather than ignoring this
On 1/13/14, 1:44 AM, Pavel Stehule wrote:
2014/1/12 Florian Pflug f...@phlo.org mailto:f...@phlo.org
On Jan12, 2014, at 22:37 , Pavel Stehule pavel.steh...@gmail.com
mailto:pavel.steh...@gmail.com wrote:
There is GUC for variable_conflict already too. In this case I would to
On Jan13, 2014, at 22:49 , Jim Nasby j...@nasby.net wrote:
ISTM that in this case, it should be safe to make the new default behavior
STRICT;
if you forget to set the GUC to disable than you'll get an error that points
directly
at the problem, at which point you'll go Oh, yeah... I forgot
On 1/14/14, 12:41 AM, Florian Pflug wrote:
In fact, after reading the documentation on SELECT ... INTO, I'm convinced the
the whole consistent_into thing is a bad idea. The documentation states clearly
that
For INSERT/UPDATE/DELETE with RETURNING, PL/pgSQL reports an error for more
than
On 01/13/2014 03:41 PM, Florian Pflug wrote:
It therefor isn't an oversight that SELECT ... INTO allows multiple result
rows
but INSERT/UPDATE/DELETE forbids them, it's been done that way on purpose and
for a reason. We shouldn't be second-guessing ourselves by changing that
later -
not,
On Jan14, 2014, at 00:52 , Marko Tiikkaja ma...@joh.to wrote:
When I've worked with PL/PgSQL, this has been a source of a few bugs that
would have been noticed during testing if the behaviour of INTO wasn't as
dangerous as it is right now.
The question is, how many bugs stemmed from wrong SQL
On 1/13/14, 5:57 PM, Josh Berkus wrote:
On 01/13/2014 03:41 PM, Florian Pflug wrote:
It therefor isn't an oversight that SELECT ... INTO allows multiple result rows
but INSERT/UPDATE/DELETE forbids them, it's been done that way on purpose and
for a reason. We shouldn't be second-guessing
On 1/13/14, 6:16 PM, Florian Pflug wrote:
On Jan14, 2014, at 00:52 , Marko Tiikkaja ma...@joh.to wrote:
When I've worked with PL/PgSQL, this has been a source of a few bugs that
would have been noticed during testing if the behaviour of INTO wasn't as
dangerous as it is right now.
The
(Responding to both of your mails here)
On Jan14, 2014, at 01:20 , Jim Nasby j...@nasby.net wrote:
On 1/13/14, 5:57 PM, Josh Berkus wrote:
On 01/13/2014 03:41 PM, Florian Pflug wrote:
It therefor isn't an oversight that SELECT ... INTO allows multiple result
rows
but INSERT/UPDATE/DELETE
Florian Pflug f...@phlo.org writes:
On Jan14, 2014, at 01:20 , Jim Nasby j...@nasby.net wrote:
And if we've always had it, why on earth didn't we make STRICT the default
behavior?
Dunno, but AFAIK pl/pgsql mimics Oracle's PL/SQL, at least in some aspects,
so maybe this is one of the areas
On 01/13/2014 04:20 PM, Jim Nasby wrote:
On 1/13/14, 5:57 PM, Josh Berkus wrote:
I *really* don't want to go through all my old code to find places where
I used SELECT ... INTO just to pop off the first row, and ignored the
rest. I doubt anyone else does, either.
Do you regularly have use
On 1/13/14, 6:36 PM, Florian Pflug wrote:
On Jan14, 2014, at 01:20 , Jim Nasbyj...@nasby.net wrote:
On 1/13/14, 5:57 PM, Josh Berkus wrote:
On 01/13/2014 03:41 PM, Florian Pflug wrote:
It therefor isn't an oversight that SELECT ... INTO allows multiple result
rows
but INSERT/UPDATE/DELETE
On 1/14/14, 1:57 AM, Tom Lane wrote:
Whatever your opinion of the default behavior, the
fact that it's been that way for upwards of fifteen years without any
mass protests should give you pause about changing it.
For what it's worth, my patch does not change the default behaviour. I
don't
On 1/13/14, 7:06 PM, Josh Berkus wrote:
On 01/13/2014 04:20 PM, Jim Nasby wrote:
On 1/13/14, 5:57 PM, Josh Berkus wrote:
I *really* don't want to go through all my old code to find places where
I used SELECT ... INTO just to pop off the first row, and ignored the
rest. I doubt anyone else
On 01/13/2014 05:10 PM, Jim Nasby wrote:
On 1/13/14, 7:06 PM, Josh Berkus wrote:
Regularly? No. But I've seen it, especially as part of a does this
query return any rows? test. That's not the best way to test that, but
that doesn't stop a lot of people doing it.
Right, and I certainly
On Sun, Jan 12, 2014 at 7:51 AM, Marko Tiikkaja ma...@joh.to wrote:
the behaviour of SELECT .. INTO when the query returns more than one row.
Some of you might know that no exception is raised in this case
Agreed. But I also agree with the rest of the thread about changing
current INTO behavior
On 2014-01-14 02:54, Marti Raudsepp wrote:
On Sun, Jan 12, 2014 at 7:51 AM, Marko Tiikkaja ma...@joh.to wrote:
the behaviour of SELECT .. INTO when the query returns more than one row.
Some of you might know that no exception is raised in this case
Agreed. But I also agree with the rest of
On 1/12/14, 7:47 AM, Pavel Stehule wrote:
2014/1/12 Marko Tiikkaja ma...@joh.to
Greetings fellow elephants,
I would humbly like to submit for your consideration my proposal for
alleviating pain caused by one of the most annoying footguns in PL/PgSQL:
the behaviour of SELECT .. INTO when the
2014/1/12 Marko Tiikkaja ma...@joh.to
On 1/12/14, 7:47 AM, Pavel Stehule wrote:
2014/1/12 Marko Tiikkaja ma...@joh.to
Greetings fellow elephants,
I would humbly like to submit for your consideration my proposal for
alleviating pain caused by one of the most annoying footguns in PL/PgSQL:
On Jan12, 2014, at 06:51 , Marko Tiikkaja ma...@joh.to wrote:
I would humbly like to submit for your consideration my proposal for
alleviating pain caused by one of the most annoying footguns in PL/PgSQL: the
behaviour of SELECT .. INTO when the query returns more than one row. Some
of you
On 1/12/14, 10:19 PM, Florian Pflug wrote:
On Jan12, 2014, at 06:51 , Marko Tiikkaja ma...@joh.to wrote:
set plpgsql.consistent_into to true;
I don't think a GUC is the best way to handle this. Handling
this via a per-function setting similar to #variable_conflict would
IMHO be better.
2014/1/12 Florian Pflug f...@phlo.org
On Jan12, 2014, at 06:51 , Marko Tiikkaja ma...@joh.to wrote:
I would humbly like to submit for your consideration my proposal for
alleviating pain caused by one of the most annoying footguns in PL/PgSQL:
the behaviour of SELECT .. INTO when the query
On Jan12, 2014, at 22:37 , Pavel Stehule pavel.steh...@gmail.com wrote:
There is GUC for variable_conflict already too. In this case I would to
enable this functionality everywhere (it is tool how to simply eliminate
some kind of strange bugs) so it needs a GUC.
We have GUC for
On 13/01/14 11:44, Florian Pflug wrote:
On Jan12, 2014, at 22:37 , Pavel Stehule pavel.steh...@gmail.com wrote:
There is GUC for variable_conflict already too. In this case I would to
enable this functionality everywhere (it is tool how to simply eliminate
some kind of strange bugs) so it
2014/1/12 Florian Pflug f...@phlo.org
On Jan12, 2014, at 22:37 , Pavel Stehule pavel.steh...@gmail.com wrote:
There is GUC for variable_conflict already too. In this case I would to
enable this functionality everywhere (it is tool how to simply eliminate
some kind of strange bugs) so it
2014/1/13 Gavin Flower gavinflo...@archidevsys.co.nz
On 13/01/14 11:44, Florian Pflug wrote:
On Jan12, 2014, at 22:37 , Pavel Stehule pavel.steh...@gmail.com wrote:
There is GUC for variable_conflict already too. In this case I would to
enable this functionality everywhere (it is tool how
2014/1/12 Florian Pflug f...@phlo.org
On Jan12, 2014, at 22:37 , Pavel Stehule pavel.steh...@gmail.com wrote:
There is GUC for variable_conflict already too. In this case I would to
enable this functionality everywhere (it is tool how to simply eliminate
some kind of strange bugs) so it
Greetings fellow elephants,
I would humbly like to submit for your consideration my proposal for
alleviating pain caused by one of the most annoying footguns in
PL/PgSQL: the behaviour of SELECT .. INTO when the query returns more
than one row. Some of you might know that no exception is
Hello
2014/1/12 Marko Tiikkaja ma...@joh.to
Greetings fellow elephants,
I would humbly like to submit for your consideration my proposal for
alleviating pain caused by one of the most annoying footguns in PL/PgSQL:
the behaviour of SELECT .. INTO when the query returns more than one row.
45 matches
Mail list logo
