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 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 rat
On Wed, Jan 15, 2014 at 8:23 AM, Jim Nasby 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
they have e
2014/1/15 Jim Nasby
> 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 unam
Jim Nasby 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 more-or-less-
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 t
Marko Tiikkaja 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, 6:15 PM, Tom Lane wrote:
Marko Tiikkaja 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 unambiguously, too, and w
Marko Tiikkaja 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 subquery
Hello
2014/1/14 Marko Tiikkaja
> 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
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
Are
2014/1/14 Marko Tiikkaja
> 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 m
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 INTO
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 l
On 1/14/14 10:16 AM, Pavel Stehule wrote:
2014/1/14 Florian Pflug
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
that language's
2014/1/14 Florian Pflug
> On Jan14, 2014, at 00:52 , Marko Tiikkaja 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 b
>> 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 (an
On 2014-01-14 02:54, Marti Raudsepp wrote:
On Sun, Jan 12, 2014 at 7:51 AM, Marko Tiikkaja 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 abou
On Sun, Jan 12, 2014 at 7:51 AM, Marko Tiikkaja 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 and introd
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 ce
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 does
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 thi
On 1/13/14, 6:36 PM, Florian Pflug wrote:
On Jan14, 2014, at 01:20 , Jim Nasby 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 forbids
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 h
Florian Pflug writes:
> On Jan14, 2014, at 01:20 , Jim Nasby 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 where we just do what o
(Responding to both of your mails here)
On Jan14, 2014, at 01:20 , Jim Nasby 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 forbi
On 1/13/14, 6:16 PM, Florian Pflug wrote:
On Jan14, 2014, at 00:52 , Marko Tiikkaja 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 man
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 ourselv
On Jan14, 2014, at 00:52 , Marko Tiikkaja 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 queries, a
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 -
> n
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
o
On Jan13, 2014, at 22:49 , Jim Nasby 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 to set X..
On 1/13/14, 1:44 AM, Pavel Stehule wrote:
2014/1/12 Florian Pflug mailto:f...@phlo.org>>
On Jan12, 2014, at 22:37 , Pavel Stehule mailto:pavel.steh...@gmail.com>> wrote:
> There is GUC for variable_conflict already too. In this case I would to
> enable this functionality everyw
2014/1/12 Florian Pflug
> On Jan12, 2014, at 22:37 , Pavel Stehule 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 GU
2014/1/13 Gavin Flower
> On 13/01/14 11:44, Florian Pflug wrote:
>
>> On Jan12, 2014, at 22:37 , Pavel Stehule 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 stra
2014/1/12 Florian Pflug
> On Jan12, 2014, at 22:37 , Pavel Stehule 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 GU
On 13/01/14 11:44, Florian Pflug wrote:
On Jan12, 2014, at 22:37 , Pavel Stehule 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 fo
On Jan12, 2014, at 22:37 , Pavel Stehule 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 plpgsql.variable_conflict thre
2014/1/12 Florian Pflug
> On Jan12, 2014, at 06:51 , Marko Tiikkaja 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 r
On 1/12/14, 10:19 PM, Florian Pflug wrote:
On Jan12, 2014, at 06:51 , Marko Tiikkaja 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.
This is exactly
On Jan12, 2014, at 06:51 , Marko Tiikkaja 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 might kn
2014/1/12 Marko Tiikkaja
> On 1/12/14, 7:47 AM, Pavel Stehule wrote:
>
>> 2014/1/12 Marko Tiikkaja
>>
>> 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
On 1/12/14, 7:47 AM, Pavel Stehule wrote:
2014/1/12 Marko Tiikkaja
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
Hello
2014/1/12 Marko Tiikkaja
> 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 o
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 rais
45 matches
Mail list logo
