Tom Lane wrote:
> The SQL standard uses "=" for assignment in other contexts,
> most notably UPDATE, but also the SQL/PSM standard uses it in
> which is the exact same thing as in
> pl/pgsql. So while purists might wish we only accepted :=, doing
> so would be inconsistent with SQL.
>
> I think
On 06/01/2013 09:22 AM, Kevin Grittner wrote:
Adrian Klaver wrote:
On 06/01/2013 06:47 AM, Kevin Grittner wrote:
Currently on an AFTER ... FOR EACH ROW we fire the trigger once
*for* each affected row, that's true. But we don't do it
immediately after the *triggering event* -- we do it imme
Adrian Klaver wrote:
> On 06/01/2013 06:47 AM, Kevin Grittner wrote:
>> Currently on an AFTER ... FOR EACH ROW we fire the trigger once
>> *for* each affected row, that's true. But we don't do it
>> immediately after the *triggering event* -- we do it immediately
>> after the *data change statem
On 06/01/2013 06:47 AM, Kevin Grittner wrote:
Adrian Klaver wrote:
On 05/31/2013 08:15 AM, Kevin Grittner wrote:
Adrian Klaver wrote:
On 05/31/2013 06:32 AM, Kevin Grittner wrote:
But why? The OP specified FOR EACH ROW in the trigger
statement.
The thing is I thought it was working
David Johnston writes:
> A bogus warning is nearly as bad as simply disallowing the syntax in the
> first place and I do not like turning one on unless there is the decision to
> disallow the syntax in the future.
TBH I do not see this happening. GET DIAGNOSTICS is just the tip of the
iceberg.
Виктор Егоров wrote
> 2013/6/1 Shenli Zhu <
> zhushenli@
> >
>
>> Hi, there are 2 columns, flag(boolean) and num(integer),in a table.
>> Table is like
>> | flag | num |
>> |--+-|
>> |1 | 2 | \ 5
>> |1 | 3 | /
>> |0 | 1 | \ 7
>> |0 | 6 | /
>> |1 | 4 | \ 9
>>
Chris Travers-5 wrote
> My preference would be that at some point we start adding warnings when =
> is used as an assignment. Such warnings could be turned off. Then at
> some
> later point we can decide whether to change the behavior. A decision to
> changing the language would be different if
2013/6/1 Shenli Zhu
> Hi, there are 2 columns, flag(boolean) and num(integer),in a table.
> Table is like
> | flag | num |
> |--+-|
> |1 | 2 | \ 5
> |1 | 3 | /
> |0 | 1 | \ 7
> |0 | 6 | /
> |1 | 4 | \ 9
> |1 | 5 | /
> | ... | ... |
> I want to sum up t
Adrian Klaver wrote:
> On 05/31/2013 08:15 AM, Kevin Grittner wrote:
>> Adrian Klaver wrote:
>>> On 05/31/2013 06:32 AM, Kevin Grittner wrote:
>>> But why? The OP specified FOR EACH ROW in the trigger
>>> statement.
>>
>> I went to the SQL spec,
>> To quote [...], the trigger should fire "eithe
Shenli Zhu wrote:
> Hi, there are 2 columns, flag(boolean) and num(integer),in a table.
> Table is like
> | flag | num |
> |--+-|
> | 1 | 2 | \ 5
> | 1 | 3 | /
> | 0 | 1 | \ 7
> | 0 | 6 | /
> | 1 | 4 | \ 9
> | 1 | 5 | /
> | ... | ... |
> I want to sum up
Hi, there are 2 columns, flag(boolean) and num(integer),in a table.
Table is like
| flag | num |
|--+-|
|1 | 2 | \ 5
|1 | 3 | /
|0 | 1 | \ 7
|0 | 6 | /
|1 | 4 | \ 9
|1 | 5 | /
| ... | ... |
I want to sum up the raw with the same continuous flags. E.g. fl
>
> A comment was made that "GET DIAGNOSTICS var = item;" is standard defined.
> Is the use of ":=" for assignment also standard defined? If so its not that
> inconsistent standards surprise me but...anyway.
":=" coming from different world (ALGOL like languages) and is never
used in SQL. Oracle
On Sat, Jun 1, 2013 at 2:52 AM, David Johnston wrote:
> Chris Travers-5 wrote
> > However = as assignment is particularly odd to me for two reasons. First
> > it is not ambiguous but it leads to difficult to read constructs, like
> > this:
> >
> >out_var = in_left = in_right;
>
> Agreed but
Chris Travers-5 wrote
> However = as assignment is particularly odd to me for two reasons. First
> it is not ambiguous but it leads to difficult to read constructs, like
> this:
>
>out_var = in_left = in_right;
Agreed but the genie is already out of the bottle and I am OK with something
at t
2013/6/1 Chris Travers :
> Agreed about undocumented behavior (actually there is a *lot* of
> undocumented behavior in PostgreSQL as I have slowly found out-- if you want
> to see a lot of it, go look at the pg_dump source code).
>
> However = as assignment is particularly odd to me for two reasons
Agreed about undocumented behavior (actually there is a *lot* of
undocumented behavior in PostgreSQL as I have slowly found out-- if you
want to see a lot of it, go look at the pg_dump source code).
However = as assignment is particularly odd to me for two reasons. First
it is not ambiguous but i
2013/6/1 David Johnston :
> Tom Lane-2 wrote
>> Stephen Frost <
>
>> sfrost@
>
>> > writes:
>>> * Moshe Jacobson (
>
>> moshe@
>
>> ) wrote:
Any PG committers who can change this in 9.3?
>>
>>> It will certainly not be changed for 9.3.
>>
>> IMO, if we do anything about this at all, it should
17 matches
Mail list logo
