pg.ddx.io pgsql-docs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #11661: CASE ELSE is evaluated although condition is true
9+ messages / 4 participants
[nested] [flat]
* BUG #11661: CASE ELSE is evaluated although condition is true
@ 2014-10-13 11:05 michael@aplaypowered.com
2014-10-13 22:54 ` Re: [BUGS] BUG #11661: CASE ELSE is evaluated although condition is true Marti Raudsepp <marti@juffo.org>
0 siblings, 1 reply; 9+ messages in thread
From: michael@aplaypowered.com @ 2014-10-13 11:05 UTC (permalink / raw)
To: pgsql-bugs@postgresql.org
The following bug has been logged on the website:
Bug reference: 11661
Logged by: Michael Stieler
Email address: michael@aplaypowered.com
PostgreSQL version: 9.2.6
Operating system: RHEL
Description:
I am not sure if it is a bug, a lack in documentation or just a
misunderstanding.
This issue refers to a StackOverflow question at
https://stackoverflow.com/questions/26297035/posgtres-case-condition-with-sum-aggregation-evaluates-...
The following query:
case when sum( column1 ) = 0
then 0
else round( sum( price
* hours
/ column1 ), 2 )
raises a division by zero error, although the condition sum(column1) = 0 is
true. I would expect that the else part would never be evaluated.
Documentation only describes that this happens for immediates.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: [BUGS] BUG #11661: CASE ELSE is evaluated although condition is true
2014-10-13 11:05 BUG #11661: CASE ELSE is evaluated although condition is true michael@aplaypowered.com
@ 2014-10-13 22:54 ` Marti Raudsepp <marti@juffo.org>
2014-11-11 07:14 ` Re: [DOCS] BUG #11661: CASE ELSE is evaluated although condition is true Michael Paquier <michael.paquier@gmail.com>
0 siblings, 1 reply; 9+ messages in thread
From: Marti Raudsepp @ 2014-10-13 22:54 UTC (permalink / raw)
To: michael@aplaypowered.com; +Cc: pgsql-docs
On Mon, Oct 13, 2014 at 2:05 PM, <michael@aplaypowered.com> wrote:
> case when sum( column1 ) = 0
> then 0
> else round( sum( price
> * hours
> / column1 ), 2 )
> I would expect that the else part would never be evaluated.
> Documentation only describes that this happens for immediates.
I explained this behavior in the Stack Overflow answer, it is caused
by way aggregates are evaluated in a SELECT (or HAVING) clause.
Our documentation should be clearer about the fact that all aggregates
are evaluated strictly before their surrounding SELECT expressions,
the attached documentation patch adds a note about this to the
"general processing of SELECT" explanation.
I also created a section "Implementation Notes" in the "Conditional
Expressions" chapter to explain this behavior, since conditionals is
where this behavior is most visible.
This similarly affects the HAVING clause:
db=# select sum(1/i) from unnest(array[0])i having min(i)>0;
ERROR: division by zero
Regards,
Marti
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
Attachments:
0001-doc-Clarify-evaluation-order-of-aggregates-wrt-condi.patch (binary/octet-stream, 2.3K) download
From 2edfe8d92f43851e3df581c24abaaba9f4de6932 Mon Sep 17 00:00:00 2001
From: Marti Raudsepp <marti@juffo.org>
Date: Tue, 14 Oct 2014 01:33:41 +0300
Subject: [PATCH] doc: Clarify evaluation order of aggregates wrt conditionals
---
doc/src/sgml/func.sgml | 19 +++++++++++++++++++
doc/src/sgml/ref/select.sgml | 4 +++-
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 3a7cfa9..76770fc 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -11251,6 +11251,25 @@ SELECT NULLIF(value, '(none)') ...
make them return NULL if any argument is NULL, rather than only when
all are NULL.
</para>
+
+ <sect2 id="implementation">
+ <title>Implementation Notes</title>
+ <para>
+ When a conditional expression depends on the results of aggregate
+ functions in a <command>SELECT</> or <literal>HAVING</> clause, then all
+ the aggregate functions are always evaluated prior to determining which
+ branch the conditional should take. For example, the following query can
+ cause a "division by zero" error despite only using division in a branch
+ that requires positive values:
+
+<programlisting>
+SELECT CASE WHEN min(employees)>0
+ THEN average(expenses / employees)
+ END
+ FROM departments
+</programlisting>
+ </para>
+
</sect2>
</sect1>
diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml
index 473939a..97b3503 100644
--- a/doc/src/sgml/ref/select.sgml
+++ b/doc/src/sgml/ref/select.sgml
@@ -111,7 +111,9 @@ TABLE [ ONLY ] <replaceable class="parameter">table_name</replaceable> [ * ]
<para>
If the <literal>GROUP BY</literal> clause is specified, the
output is combined into groups of rows that match on one or more
- values. If the <literal>HAVING</literal> clause is present, it
+ values. All aggregate functions and their argument expressions
+ in the <command>SELECT</> and <literal>HAVING</> are evaluated.
+ If the <literal>HAVING</literal> clause is present, it
eliminates groups that do not satisfy the given condition. (See
<xref linkend="sql-groupby" endterm="sql-groupby-title"> and
<xref linkend="sql-having" endterm="sql-having-title"> below.)
--
2.1.2
* Re: [DOCS] BUG #11661: CASE ELSE is evaluated although condition is true
2014-10-13 11:05 BUG #11661: CASE ELSE is evaluated although condition is true michael@aplaypowered.com
2014-10-13 22:54 ` Re: [BUGS] BUG #11661: CASE ELSE is evaluated although condition is true Marti Raudsepp <marti@juffo.org>
@ 2014-11-11 07:14 ` Michael Paquier <michael.paquier@gmail.com>
2014-11-11 07:37 ` Re: [BUGS] BUG #11661: CASE ELSE is evaluated although condition is true Marti Raudsepp <marti@juffo.org>
0 siblings, 1 reply; 9+ messages in thread
From: Michael Paquier @ 2014-11-11 07:14 UTC (permalink / raw)
To: Marti Raudsepp <marti@juffo.org>; +Cc: pgsql-docs
On Tue, Oct 14, 2014 at 7:54 AM, Marti Raudsepp <marti@juffo.org> wrote:
> Our documentation should be clearer about the fact that all aggregates
> are evaluated strictly before their surrounding SELECT expressions,
> the attached documentation patch adds a note about this to the
> "general processing of SELECT" explanation.
This patch does not compile properly as a </sect2> is missing, and I
think that you actually want to add this sect2 block at the bottom the
sect1 block for conditional functions. "implementation" is as well a
bit too general to name such a section, something like
"functions-conditional-implementation" would be better. Also, I am a
bit dubious about adding a mention aggregate functions and their
elements being evaluated in a paragraph for GROUP BY and HAVING
clause. All together only mentioning that in the conditional function
block sound enough. All those things grouped together result in the
attached. Marti, feel free to comment and correct what you think is
wrong :)
Regards,
--
Michael
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Attachments:
20141111_conditional_funcs_doc.patch (binary/octet-stream, 1003B) download
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 7e5bcd9..7f04e504 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -11254,6 +11254,25 @@ SELECT NULLIF(value, '(none)') ...
all are NULL.
</para>
</sect2>
+
+ <sect2 id="functions-conditional-implementation">
+ <title>Implementation Notes</title>
+ <para>
+ When a conditional expression depends on the results of aggregate
+ functions in a <command>SELECT</> or <literal>HAVING</> clause, then all
+ the aggregate functions are always evaluated prior to determining which
+ branch the conditional should take. For example, the following query can
+ cause a division-by-zero error despite only using division in a branch
+ that requires positive values:
+
+<programlisting>
+SELECT CASE WHEN min(employees) > 0
+ THEN average(expenses / employees)
+ END
+ FROM departments;
+</programlisting>
+ </para>
+ </sect2>
</sect1>
<sect1 id="functions-array">
* Re: [BUGS] BUG #11661: CASE ELSE is evaluated although condition is true
2014-10-13 11:05 BUG #11661: CASE ELSE is evaluated although condition is true michael@aplaypowered.com
2014-10-13 22:54 ` Re: [BUGS] BUG #11661: CASE ELSE is evaluated although condition is true Marti Raudsepp <marti@juffo.org>
2014-11-11 07:14 ` Re: [DOCS] BUG #11661: CASE ELSE is evaluated although condition is true Michael Paquier <michael.paquier@gmail.com>
@ 2014-11-11 07:37 ` Marti Raudsepp <marti@juffo.org>
2014-11-11 07:52 ` Re: [BUGS] BUG #11661: CASE ELSE is evaluated although condition is true Michael Paquier <michael.paquier@gmail.com>
0 siblings, 1 reply; 9+ messages in thread
From: Marti Raudsepp @ 2014-11-11 07:37 UTC (permalink / raw)
To: Michael Paquier <michael.paquier@gmail.com>; +Cc: pgsql-docs
Hi
On Tue, Nov 11, 2014 at 9:14 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> This patch does not compile properly as a </sect2> is missing, and I
> think that you actually want to add this sect2 block at the bottom the
> sect1 block for conditional functions.
Sorry, I never got around to testing the build because I found a
working DocBook envrionment a PITA to set up. Should have mentioned
that in my email.
> "implementation" is as well a
> bit too general to name such a section, something like
> "functions-conditional-implementation" would be better.
+1
> Also, I am a
> bit dubious about adding a mention aggregate functions and their
> elements being evaluated in a paragraph for GROUP BY and HAVING
> clause.
Why? This page explains in what order the expressions in a SELECT
query are processed. Aggregates can only be found in SELECT queries
and their semantics are non-trivial, so it seems like a big omission
to me that their relation to other clauses is not discussed.
I think that's the most appropriate place for that, because GROUP BY,
HAVING and aggregates are closely related. And their execution occurs
after evaluating GROUP BY keys and before HAVING predicates, where
else would one put it?
Regards,
Marti
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: [BUGS] BUG #11661: CASE ELSE is evaluated although condition is true
2014-10-13 11:05 BUG #11661: CASE ELSE is evaluated although condition is true michael@aplaypowered.com
2014-10-13 22:54 ` Re: [BUGS] BUG #11661: CASE ELSE is evaluated although condition is true Marti Raudsepp <marti@juffo.org>
2014-11-11 07:14 ` Re: [DOCS] BUG #11661: CASE ELSE is evaluated although condition is true Michael Paquier <michael.paquier@gmail.com>
2014-11-11 07:37 ` Re: [BUGS] BUG #11661: CASE ELSE is evaluated although condition is true Marti Raudsepp <marti@juffo.org>
@ 2014-11-11 07:52 ` Michael Paquier <michael.paquier@gmail.com>
2014-11-11 08:26 ` Re: [BUGS] BUG #11661: CASE ELSE is evaluated although condition is true Marti Raudsepp <marti@juffo.org>
0 siblings, 1 reply; 9+ messages in thread
From: Michael Paquier @ 2014-11-11 07:52 UTC (permalink / raw)
To: Marti Raudsepp <marti@juffo.org>; +Cc: pgsql-docs
On Tue, Nov 11, 2014 at 4:37 PM, Marti Raudsepp <marti@juffo.org> wrote:
> Why? This page explains in what order the expressions in a SELECT
> query are processed. Aggregates can only be found in SELECT queries
> and their semantics are non-trivial, so it seems like a big omission
> to me that their relation to other clauses is not discussed.
>
> I think that's the most appropriate place for that, because GROUP BY,
> HAVING and aggregates are closely related. And their execution occurs
> after evaluating GROUP BY keys and before HAVING predicates, where
> else would one put it?
Ah, OK. I wasn't aware of this execution order. Now we could as well
split the description flow into more tiny paragraphs but this does not
seem worth it. So what about the attached then?
--
Michael
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
Attachments:
20141111_conditional_funcs_doc_v2.patch (application/x-patch, 2.0K) download
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 7e5bcd9..7f04e504 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -11254,6 +11254,25 @@ SELECT NULLIF(value, '(none)') ...
all are NULL.
</para>
</sect2>
+
+ <sect2 id="functions-conditional-implementation">
+ <title>Implementation Notes</title>
+ <para>
+ When a conditional expression depends on the results of aggregate
+ functions in a <command>SELECT</> or <literal>HAVING</> clause, then all
+ the aggregate functions are always evaluated prior to determining which
+ branch the conditional should take. For example, the following query can
+ cause a division-by-zero error despite only using division in a branch
+ that requires positive values:
+
+<programlisting>
+SELECT CASE WHEN min(employees) > 0
+ THEN average(expenses / employees)
+ END
+ FROM departments;
+</programlisting>
+ </para>
+ </sect2>
</sect1>
<sect1 id="functions-array">
diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml
index 473939a..36f4941 100644
--- a/doc/src/sgml/ref/select.sgml
+++ b/doc/src/sgml/ref/select.sgml
@@ -111,9 +111,11 @@ TABLE [ ONLY ] <replaceable class="parameter">table_name</replaceable> [ * ]
<para>
If the <literal>GROUP BY</literal> clause is specified, the
output is combined into groups of rows that match on one or more
- values. If the <literal>HAVING</literal> clause is present, it
- eliminates groups that do not satisfy the given condition. (See
- <xref linkend="sql-groupby" endterm="sql-groupby-title"> and
+ values. All aggregate functions and their argument expressions
+ in the <command>SELECT</> and <literal>HAVING</> are evaluated.
+ If the <literal>HAVING</literal> clause is present, it eliminates
+ groups that do not satisfy the given condition. (See
+ <xref linkend="sql-groupby" endterm="sql-groupby-title">, and
<xref linkend="sql-having" endterm="sql-having-title"> below.)
</para>
</listitem>
* Re: [BUGS] BUG #11661: CASE ELSE is evaluated although condition is true
2014-10-13 11:05 BUG #11661: CASE ELSE is evaluated although condition is true michael@aplaypowered.com
2014-10-13 22:54 ` Re: [BUGS] BUG #11661: CASE ELSE is evaluated although condition is true Marti Raudsepp <marti@juffo.org>
2014-11-11 07:14 ` Re: [DOCS] BUG #11661: CASE ELSE is evaluated although condition is true Michael Paquier <michael.paquier@gmail.com>
2014-11-11 07:37 ` Re: [BUGS] BUG #11661: CASE ELSE is evaluated although condition is true Marti Raudsepp <marti@juffo.org>
2014-11-11 07:52 ` Re: [BUGS] BUG #11661: CASE ELSE is evaluated although condition is true Michael Paquier <michael.paquier@gmail.com>
@ 2014-11-11 08:26 ` Marti Raudsepp <marti@juffo.org>
2014-11-11 13:20 ` Re: [DOCS] BUG #11661: CASE ELSE is evaluated although condition is true Michael Paquier <michael.paquier@gmail.com>
0 siblings, 1 reply; 9+ messages in thread
From: Marti Raudsepp @ 2014-11-11 08:26 UTC (permalink / raw)
To: Michael Paquier <michael.paquier@gmail.com>; +Cc: pgsql-docs
On Tue, Nov 11, 2014 at 9:52 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> Ah, OK. I wasn't aware of this execution order. Now we could as well
> split the description flow into more tiny paragraphs but this does not
> seem worth it.
Agreed.
Actually now that I read it...
+ values. All aggregate functions and their argument expressions
+ in the <command>SELECT</> and <literal>HAVING</> are evaluated.
Perhaps should be:
<command>SELECT</> and <literal>HAVING</> clauses are evaluated.
Other than that, looks good to me.
Regards,
Marti
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: [DOCS] BUG #11661: CASE ELSE is evaluated although condition is true
2014-10-13 11:05 BUG #11661: CASE ELSE is evaluated although condition is true michael@aplaypowered.com
2014-10-13 22:54 ` Re: [BUGS] BUG #11661: CASE ELSE is evaluated although condition is true Marti Raudsepp <marti@juffo.org>
2014-11-11 07:14 ` Re: [DOCS] BUG #11661: CASE ELSE is evaluated although condition is true Michael Paquier <michael.paquier@gmail.com>
2014-11-11 07:37 ` Re: [BUGS] BUG #11661: CASE ELSE is evaluated although condition is true Marti Raudsepp <marti@juffo.org>
2014-11-11 07:52 ` Re: [BUGS] BUG #11661: CASE ELSE is evaluated although condition is true Michael Paquier <michael.paquier@gmail.com>
2014-11-11 08:26 ` Re: [BUGS] BUG #11661: CASE ELSE is evaluated although condition is true Marti Raudsepp <marti@juffo.org>
@ 2014-11-11 13:20 ` Michael Paquier <michael.paquier@gmail.com>
2014-11-11 14:19 ` Re: [DOCS] BUG #11661: CASE ELSE is evaluated although condition is true Marti Raudsepp <marti@juffo.org>
2014-11-14 22:21 ` Re: [DOCS] BUG #11661: CASE ELSE is evaluated although condition is true Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 9+ messages in thread
From: Michael Paquier @ 2014-11-11 13:20 UTC (permalink / raw)
To: Marti Raudsepp <marti@juffo.org>; +Cc: pgsql-docs
On Tue, Nov 11, 2014 at 5:26 PM, Marti Raudsepp <marti@juffo.org> wrote:
> Perhaps should be:
> <command>SELECT</> and <literal>HAVING</> clauses are evaluated.
>
> Other than that, looks good to me.
Let's do so then and mark that as ready for committer.
Thanks,
--
Michael
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Attachments:
20141111_conditional_funcs_doc_v3.patch (application/x-patch, 2.1K) download
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index b58cfa5..2d5e0d3 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -11254,6 +11254,25 @@ SELECT NULLIF(value, '(none)') ...
all are NULL.
</para>
</sect2>
+
+ <sect2 id="functions-conditional-implementation">
+ <title>Implementation Notes</title>
+ <para>
+ When a conditional expression depends on the results of aggregate
+ functions in a <command>SELECT</> or <literal>HAVING</> clause, then all
+ the aggregate functions are always evaluated prior to determining which
+ branch the conditional should take. For example, the following query can
+ cause a division-by-zero error despite only using division in a branch
+ that requires positive values:
+
+<programlisting>
+SELECT CASE WHEN min(employees) > 0
+ THEN average(expenses / employees)
+ END
+ FROM departments;
+</programlisting>
+ </para>
+ </sect2>
</sect1>
<sect1 id="functions-array">
diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml
index 473939a..7001ea6 100644
--- a/doc/src/sgml/ref/select.sgml
+++ b/doc/src/sgml/ref/select.sgml
@@ -111,9 +111,11 @@ TABLE [ ONLY ] <replaceable class="parameter">table_name</replaceable> [ * ]
<para>
If the <literal>GROUP BY</literal> clause is specified, the
output is combined into groups of rows that match on one or more
- values. If the <literal>HAVING</literal> clause is present, it
- eliminates groups that do not satisfy the given condition. (See
- <xref linkend="sql-groupby" endterm="sql-groupby-title"> and
+ values. All aggregate functions and their argument expressions
+ in <command>SELECT</literal> and <literal>HAVING</literal> clauses
+ are evaluated. If the <literal>HAVING</literal> clause is present,
+ it eliminates groups that do not satisfy the given condition. (See
+ <xref linkend="sql-groupby" endterm="sql-groupby-title">, and
<xref linkend="sql-having" endterm="sql-having-title"> below.)
</para>
</listitem>
* Re: [DOCS] BUG #11661: CASE ELSE is evaluated although condition is true
2014-10-13 11:05 BUG #11661: CASE ELSE is evaluated although condition is true michael@aplaypowered.com
2014-10-13 22:54 ` Re: [BUGS] BUG #11661: CASE ELSE is evaluated although condition is true Marti Raudsepp <marti@juffo.org>
2014-11-11 07:14 ` Re: [DOCS] BUG #11661: CASE ELSE is evaluated although condition is true Michael Paquier <michael.paquier@gmail.com>
2014-11-11 07:37 ` Re: [BUGS] BUG #11661: CASE ELSE is evaluated although condition is true Marti Raudsepp <marti@juffo.org>
2014-11-11 07:52 ` Re: [BUGS] BUG #11661: CASE ELSE is evaluated although condition is true Michael Paquier <michael.paquier@gmail.com>
2014-11-11 08:26 ` Re: [BUGS] BUG #11661: CASE ELSE is evaluated although condition is true Marti Raudsepp <marti@juffo.org>
2014-11-11 13:20 ` Re: [DOCS] BUG #11661: CASE ELSE is evaluated although condition is true Michael Paquier <michael.paquier@gmail.com>
@ 2014-11-11 14:19 ` Marti Raudsepp <marti@juffo.org>
1 sibling, 0 replies; 9+ messages in thread
From: Marti Raudsepp @ 2014-11-11 14:19 UTC (permalink / raw)
To: Michael Paquier <michael.paquier@gmail.com>; +Cc: pgsql-docs
On Tue, Nov 11, 2014 at 3:20 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Tue, Nov 11, 2014 at 5:26 PM, Marti Raudsepp <marti@juffo.org> wrote:
>> Perhaps should be:
>> <command>SELECT</> and <literal>HAVING</> clauses are evaluated.
> Let's do so then
Oops, that should be my task, but you got there first. :)
> and mark that as ready for committer.
Thanks!
Regards,
Marti
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: [DOCS] BUG #11661: CASE ELSE is evaluated although condition is true
2014-10-13 11:05 BUG #11661: CASE ELSE is evaluated although condition is true michael@aplaypowered.com
2014-10-13 22:54 ` Re: [BUGS] BUG #11661: CASE ELSE is evaluated although condition is true Marti Raudsepp <marti@juffo.org>
2014-11-11 07:14 ` Re: [DOCS] BUG #11661: CASE ELSE is evaluated although condition is true Michael Paquier <michael.paquier@gmail.com>
2014-11-11 07:37 ` Re: [BUGS] BUG #11661: CASE ELSE is evaluated although condition is true Marti Raudsepp <marti@juffo.org>
2014-11-11 07:52 ` Re: [BUGS] BUG #11661: CASE ELSE is evaluated although condition is true Michael Paquier <michael.paquier@gmail.com>
2014-11-11 08:26 ` Re: [BUGS] BUG #11661: CASE ELSE is evaluated although condition is true Marti Raudsepp <marti@juffo.org>
2014-11-11 13:20 ` Re: [DOCS] BUG #11661: CASE ELSE is evaluated although condition is true Michael Paquier <michael.paquier@gmail.com>
@ 2014-11-14 22:21 ` Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 9+ messages in thread
From: Tom Lane @ 2014-11-14 22:21 UTC (permalink / raw)
To: Michael Paquier <michael.paquier@gmail.com>; +Cc: Marti Raudsepp <marti@juffo.org>; pgsql-docs
Michael Paquier <michael.paquier@gmail.com> writes:
> On Tue, Nov 11, 2014 at 5:26 PM, Marti Raudsepp <marti@juffo.org> wrote:
>> Perhaps should be:
>> <command>SELECT</> and <literal>HAVING</> clauses are evaluated.
>>
>> Other than that, looks good to me.
> Let's do so then and mark that as ready for committer.
I rewrote this somewhat and committed it.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
^ permalink raw reply [nested|flat] 9+ messages in thread
end of thread, other threads:[~2014-11-14 22:21 UTC | newest]
Thread overview: 9+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2014-10-13 11:05 BUG #11661: CASE ELSE is evaluated although condition is true michael@aplaypowered.com
2014-10-13 22:54 ` Marti Raudsepp <marti@juffo.org>
2014-11-11 07:14 ` Michael Paquier <michael.paquier@gmail.com>
2014-11-11 07:37 ` Marti Raudsepp <marti@juffo.org>
2014-11-11 07:52 ` Michael Paquier <michael.paquier@gmail.com>
2014-11-11 08:26 ` Marti Raudsepp <marti@juffo.org>
2014-11-11 13:20 ` Michael Paquier <michael.paquier@gmail.com>
2014-11-11 14:19 ` Marti Raudsepp <marti@juffo.org>
2014-11-14 22:21 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox