agora inbox for pgsql-bugs@postgresql.org
help / color / mirror / Atom feedSubstring auto trim
10+ messages / 6 participants
[nested] [flat]
* Substring auto trim
@ 2010-01-13 09:02 Charles O'Farrell <charleso@gmail.com>
0 siblings, 2 replies; 10+ messages in thread
From: Charles O'Farrell @ 2010-01-13 09:02 UTC (permalink / raw)
To: pgsql-bugs
Hi guys,
I'm not sure whether this a really dumb question, but I'm curious as to what
might be the problem.
We have a column 'foo' which is of type character (not varying).
select substr(foo, 1, 10) from bar
The result of this query are values whose trailing spaces have been trimmed
automatically. This causes incorrect results when comparing to a value that
may contain trailing spaces.
select * from bar where substr(foo, 1, 4) = 'AB '
I should mention that we normally run Oracle and DB2 (and have done for many
years), but I have been pushing for Postgres as an alternative.
Fortunately this is all handled through Hibernate, and so for now I have
wrapped the substr command in rpad which seems to do the trick.
Any light you can shed on this issue would be much appreciated.
Cheers,
Charles O'Farrell
PostgreSQL 8.4.2 on i486-pc-linux-gnu, compiled by GCC gcc-4.4.real (Ubuntu
4.4.1-4ubuntu8) 4.4.1, 32-bit
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Substring auto trim
@ 2010-01-13 13:36 Pavel Stehule <pavel.stehule@gmail.com>
parent: Charles O'Farrell <charleso@gmail.com>
1 sibling, 1 reply; 10+ messages in thread
From: Pavel Stehule @ 2010-01-13 13:36 UTC (permalink / raw)
To: Charles O'Farrell <charleso@gmail.com>; +Cc: pgsql-bugs
Hello
2010/1/13 Charles O'Farrell <charleso@gmail.com>:
> Hi guys,
>
> I'm not sure whether this a really dumb question, but I'm curious as to what
> might be the problem.
>
> We have a column 'foo' which is of type character (not varying).
>
> select substr(foo, 1, 10) from bar
>
> The result of this query are values whose trailing spaces have been trimmed
> automatically. This causes incorrect results when comparing to a value that
> may contain trailing spaces.
>
> select * from bar where substr(foo, 1, 4) = 'AB '
>
You have to write C function substr for type "any" :( Because "char"
and char(n) are two different types, and you cannot to write function
for char(n)
> I should mention that we normally run Oracle and DB2 (and have done for many
> years), but I have been pushing for Postgres as an alternative.
> Fortunately this is all handled through Hibernate, and so for now I have
> wrapped the substr command in rpad which seems to do the trick.
>
> Any light you can shed on this issue would be much appreciated.
>
Function substr has first parameter of type "text". When pg call this
function, then it does conversion from char(x) to text.
Regards
Pavel Stehule
> Cheers,
>
> Charles O'Farrell
>
> PostgreSQL 8.4.2 on i486-pc-linux-gnu, compiled by GCC gcc-4.4.real (Ubuntu
> 4.4.1-4ubuntu8) 4.4.1, 32-bit
>
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Substring auto trim
@ 2010-01-13 13:55 Pavel Stehule <pavel.stehule@gmail.com>
parent: Pavel Stehule <pavel.stehule@gmail.com>
0 siblings, 0 replies; 10+ messages in thread
From: Pavel Stehule @ 2010-01-13 13:55 UTC (permalink / raw)
To: Charles O'Farrell <charleso@gmail.com>; +Cc: pgsql-bugs
2010/1/13 Pavel Stehule <pavel.stehule@gmail.com>:
> Hello
>
> 2010/1/13 Charles O'Farrell <charleso@gmail.com>:
>> Hi guys,
>>
>> I'm not sure whether this a really dumb question, but I'm curious as to what
>> might be the problem.
>>
>> We have a column 'foo' which is of type character (not varying).
>>
>> select substr(foo, 1, 10) from bar
>>
>> The result of this query are values whose trailing spaces have been trimmed
>> automatically. This causes incorrect results when comparing to a value that
>> may contain trailing spaces.
>>
>> select * from bar where substr(foo, 1, 4) = 'AB '
>>
>
> You have to write C function substr for type "any" :( Because "char"
> and char(n) are two different types, and you cannot to write function
> for char(n)
>
>
>> I should mention that we normally run Oracle and DB2 (and have done for many
>> years), but I have been pushing for Postgres as an alternative.
>> Fortunately this is all handled through Hibernate, and so for now I have
>> wrapped the substr command in rpad which seems to do the trick.
>>
>> Any light you can shed on this issue would be much appreciated.
>>
I thing, so there is workaround,
create or replace function substr(character, int, int) returns character as $$
select substr($1::cstring::text,$2,$3)
$$ language sql;
postgres=# create table f(a character(5));
CREATE TABLE
postgres=# insert into f values('a'),('ab'),('abc');
INSERT 0 3
postgres=# select * from f;
a
-------
a
ab
abc
(3 rows)
postgres=# select * from f where substr(a,1,3) = 'a ';
a
-------
a
(1 row)
postgres=# select * from f where substr(a,1,3) = 'ab ';
a
-------
ab
(1 row)
Regards
Pavel Stehule
>
> Function substr has first parameter of type "text". When pg call this
> function, then it does conversion from char(x) to text.
>
> Regards
> Pavel Stehule
>
>
>> Cheers,
>>
>> Charles O'Farrell
>>
>> PostgreSQL 8.4.2 on i486-pc-linux-gnu, compiled by GCC gcc-4.4.real (Ubuntu
>> 4.4.1-4ubuntu8) 4.4.1, 32-bit
>>
>
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Substring auto trim
@ 2010-01-13 15:35 Tom Lane <tgl@sss.pgh.pa.us>
parent: Charles O'Farrell <charleso@gmail.com>
1 sibling, 1 reply; 10+ messages in thread
From: Tom Lane @ 2010-01-13 15:35 UTC (permalink / raw)
To: Charles O'Farrell <charleso@gmail.com>; +Cc: pgsql-bugs
"Charles O'Farrell" <charleso@gmail.com> writes:
> We have a column 'foo' which is of type character (not varying).
> select substr(foo, 1, 10) from bar
> The result of this query are values whose trailing spaces have been trimmed
> automatically. This causes incorrect results when comparing to a value that
> may contain trailing spaces.
What's the data type of the value being compared to? I get, for instance,
postgres=# select substr('ab '::char(4), 1, 4) = 'ab '::char(4);
?column?
----------
t
(1 row)
The actual value coming out of the substr() is indeed just 'ab',
but that ought to be considered equal to 'ab ' anyway in char(n)
semantics.
Postgres considers that trailing blanks in a char(n) value are
semantically insignificant, so it strips them when converting to a type
where they would be significant (ie, text or varchar). What's happening
in this scenario is that substr() is defined to take and return text,
so the stripping happens before substr ever sees it.
As Pavel noted, you could possibly work around this particular case by
defining a variant of substr() that takes and returns char(n), but on
the whole I'd strongly advise switching over to varchar/text if
possible. The semantics of char(n) are so weird/braindamaged that
it's best avoided.
BTW, if you do want to use the workaround, this seems sufficient:
create function substr(char,int,int) returns char
strict immutable language internal as 'text_substr' ;
It's the same C code, you're just avoiding the coercion on input.
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Substring auto trim
@ 2010-01-13 16:01 Kevin Grittner <Kevin.Grittner@wicourts.gov>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 10+ messages in thread
From: Kevin Grittner @ 2010-01-13 16:01 UTC (permalink / raw)
To: Charles O'Farrell <charleso@gmail.com>; Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-bugs
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> What's the data type of the value being compared to? I get, for
> instance,
>
> postgres=# select substr('ab '::char(4), 1, 4) = 'ab '::char(4);
> ?column?
> ----------
> t
> (1 row)
This looks like another situation where we're running into trouble
because of non-standard behavior when people might be expecting
something consistent with other products and the explicit language
in the standard.
Quoting from section 5.3 of "WG3:HBA-003 H2-2003-305 August, 2003
(ISO-ANSI Working Draft) Foundation (SQL/Foundation)":
| 13) The declared type of a <character string literal> is
| fixed-length character string. The length of a <character
| string literal> is the number of <character representation>s
| that it contains. Each <quote symbol> contained in <character
| string literal> represents a single <quote> in both the value
| and the length of the <character string literal>. The two
| <quote>s contained in a <quote symbol> shall not be separated
| by any <separator>.
|
| NOTE 72 * <character string literal>s are allowed to be
| zero-length strings (i.e., to contain no characters) even
| though it is not permitted to declare a <data type> that is
| CHARACTER with <length> 0 (zero).
Based on that, the cast of the literals to char(4) in your example
should not be needed. I don't know if there's any reasonable fix
or if this should be handled with a doc change or FAQ entry.
-Kevin
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Substring auto trim
@ 2010-01-13 17:14 Tom Lane <tgl@sss.pgh.pa.us>
parent: Kevin Grittner <Kevin.Grittner@wicourts.gov>
0 siblings, 1 reply; 10+ messages in thread
From: Tom Lane @ 2010-01-13 17:14 UTC (permalink / raw)
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>; +Cc: Charles O'Farrell <charleso@gmail.com>; pgsql-bugs
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> What's the data type of the value being compared to? I get, for
>> instance,
>>
>> postgres=# select substr('ab '::char(4), 1, 4) = 'ab '::char(4);
> This looks like another situation where we're running into trouble
> because of non-standard behavior when people might be expecting
> something consistent with other products and the explicit language
> in the standard.
If we were to change that so that 'ab ' were implicitly typed as
char(4), then we'd start getting bug reports from people complaining
that "select 'ab' = 'ab '" yields true. I remain of the opinion that
char(n) is so hopelessly brain-damaged that we should be very careful
to NOT bring it into our mainstream behavior.
regards, tom lane
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Substring auto trim
@ 2010-01-13 17:21 Kevin Grittner <Kevin.Grittner@wicourts.gov>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 10+ messages in thread
From: Kevin Grittner @ 2010-01-13 17:21 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Charles O'Farrell <charleso@gmail.com>; pgsql-bugs
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
>> This looks like another situation where we're running into
>> trouble because of non-standard behavior when people might be
>> expecting something consistent with other products and the
>> explicit language in the standard.
>
> If we were to change that so that 'ab ' were implicitly typed as
> char(4), then we'd start getting bug reports from people
> complaining that "select 'ab' = 'ab '" yields true. I remain of
> the opinion that char(n) is so hopelessly brain-damaged that we
> should be very careful to NOT bring it into our mainstream
> behavior.
I'm inclined to agree with you, but it does present a barrier to
those migrating. Are there any "migration considerations" documents
where we should mention this? Standards compliance notes in the
docs? Some form of this question seems to be asked frequently....
-Kevin
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Substring auto trim
@ 2010-01-13 22:20 Charles O'Farrell <charleso@gmail.com>
parent: Kevin Grittner <Kevin.Grittner@wicourts.gov>
0 siblings, 0 replies; 10+ messages in thread
From: Charles O'Farrell @ 2010-01-13 22:20 UTC (permalink / raw)
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-bugs
On Thu, Jan 14, 2010 at 3:21 AM, Kevin Grittner <Kevin.Grittner@wicourts.gov
> wrote:
>
> I'm inclined to agree with you, but it does present a barrier to
> those migrating. Are there any "migration considerations" documents
> where we should mention this? Standards compliance notes in the
> docs? Some form of this question seems to be asked frequently....
>
>
Many thanks for the quick and detailed responses. Looks like we'll have to
stick with that work around for now.
Part of the problem for us re: varchars is that we are using Cobol where
trailing spaces are significant and litter all our data and queries.
Thanks again.
Charles
^ permalink raw reply [nested|flat] 10+ messages in thread
* BUG #19560: Wrong results since v16: removable LEFT JOIN silently drops WHERE qual
@ 2026-07-20 09:44 PG Bug reporting form <noreply@postgresql.org>
0 siblings, 1 reply; 10+ messages in thread
From: PG Bug reporting form @ 2026-07-20 09:44 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: orestis@orestis.gr
The following bug has been logged on the website:
Bug reference: 19560
Logged by: Orestis Markou
Email address: orestis@orestis.gr
PostgreSQL version: 19beta2
Operating system: Debian (official Docker images), aarch64
Description:
I got a customer-reported bug and managed to narrow it down with the help of
Claude:
```
CREATE TABLE items (id text, owner text);
CREATE TABLE follows (item_id text, user_id text, UNIQUE (user_id,
item_id));
INSERT INTO items VALUES ('item1', 'alice');
WITH viewer AS (SELECT 'bob' AS id)
SELECT count(*) FROM items
LEFT JOIN follows ON follows.item_id = items.id AND follows.user_id = 'bob'
LEFT JOIN viewer ON TRUE
WHERE items.owner = viewer.id;
```
Expected 0 ('alice' <> 'bob'). Actual: 1. EXPLAIN shows the viewer join and
the WHERE qual gone entirely:
Aggregate
-> Seq Scan on items
Any ONE of these restores correct behavior:
- drop the UNIQUE constraint on follows (blocks its removal as a useless
join)
- WITH viewer AS MATERIALIZED
- WHERE items.owner IS NOT DISTINCT FROM viewer.id (non-strict qual)
So it needs: a removable LEFT JOIN elsewhere + a pulled-up one-row subquery
+ a strict qual on the subquery's column.
This is a regression from 15.18 to 16.0. I tested this exact same repro
across all major versions up until and including 19-beta2.
Related to BUG #19553 but a different defect: built 19beta2 from source,
applied the patch from that thread (find_dependent_phvs phrels
membership-vs-exact-match fix in prepjointree.c) — it fixes #19553's own
repro but does not fix this one (still returns 1, same plan).
Workaround: WHERE items.owner = (SELECT id FROM viewer) — scalar subquery
plans as an InitPlan Param, unaffected.
--
I've asked Claude to try and do an analysis of why this is caused and it
ended up with this (validated within the beta2 source code):
Root cause traced on 19beta2 (debug build; cassert raises nothing —
silent wrong results). Relids: 1=items, 2=follows, 3=follows-OJ,
4=viewer.
The chain:
* Pull-up wraps the CTE's constant in a PlaceHolderVar:
PHV(Const 'bob'), phrels={4} (nullable side of a LEFT JOIN).
* Strict WHERE qual => reduce_outer_joins_pass2() (prepjointree.c
~3501) reduces the viewer join to inner; phnullingrels becomes
empty. PHV is now semantically a plain constant.
* remove_useless_results_recurse() drops the viewer RTE_RESULT;
substitute_phv_relids() relocates phrels to the OTHER join side:
{1,2,3}. Phantom dependency on follows.
* make_eq_member() (equivclass.c ~605) tests
bms_is_empty(pull_varnos()); PHV returns phrels={1,2,3}, so
ec_has_const=false despite the Const inside.
* No-const path of generate_base_implied_equalities() (~1398) skips
non-singleton members => no "items.owner='bob'" base restriction.
The equality survives only as a future join clause at {1,2,3}.
* remove_useless_joins() removes the follows join
(join_is_removable() checks attr_needed/ph_eval_at, not EC relids).
remove_rel_from_eclass() (analyzejoins.c ~773) strips relids 2,3
but nothing re-derives the collapsed equality. Qual gone.
Instrumented EC state at removal (elog in remove_rel_from_eclass):
member Var items.owner em_relids {1}; member PHV{Const 'bob',
phrels {1,2,3}, phnullingrels {}} em_relids {1,2,3};
ec_has_const=false; ec_derives empty.
--
This is all going above my head, and I wouldn't dare propose a patch here,
but hopefully this analysis might save someone some time...
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: BUG #19560: Wrong results since v16: removable LEFT JOIN silently drops WHERE qual
@ 2026-07-24 16:50 Nitin Motiani <nitinmotiani@google.com>
parent: PG Bug reporting form <noreply@postgresql.org>
0 siblings, 0 replies; 10+ messages in thread
From: Nitin Motiani @ 2026-07-24 16:50 UTC (permalink / raw)
To: orestis@orestis.gr; pgsql-bugs@lists.postgresql.org
Hi,
Thanks for this detail. I'm not very familiar with this code but this
analysis helped me find the functions and understand it a little
better. I have started working on a WIP patch which I'm attaching
here. I think changing the PHV to the const if phnullingrels size goes
to zero might fix this.
I'm not sure of this approach because a comment warns against removing
PHV if phnullingrels are removed. But I have only done this in the
cases when `is_pseudo_constant_clause` returns true. I'll spend some
more time on this to understand the complete flow. For now, I'm
sending the WIP patch to get feedback.
Attachments:
[application/x-patch] WIP-v1-0001-WIP-Convert-PHVs-to-constants-if-phnullringrels-w.patch (4.6K, ../../CAH5HC97SU+JHHT4rJo76ZO09KVmZZh=bF_ZA67YLq4q-Vv3Weg@mail.gmail.com/2-WIP-v1-0001-WIP-Convert-PHVs-to-constants-if-phnullringrels-w.patch)
download | inline diff:
From 5f0135fd8e9cf6d6b0305e213ce5fada1896a4e6 Mon Sep 17 00:00:00 2001
From: Nitin Motiani <nitinmotiani@google.com>
Date: Fri, 24 Jul 2026 14:18:10 +0000
Subject: [WIP] Convert PHVs to constants if phnullringrels went to
0
This approach dissolves constant PHVs immediately when they lose their
nullability (phnullingrels becomes empty) during outer join reduction or
useless relation removal. A safety guard "orig_size > 0 && size == 0"
ensures we only dissolve PHVs that were actually nullable before,
avoiding regressions in FULL JOIN queries with constant keys.
This is WIP because there is a comment warning agains it. The intention
is to do this only in the narrow case. But it perhaps requires more analysis.
---
src/backend/rewrite/rewriteManip.c | 36 +++++++++++++++++++++++++-----
src/test/regress/sql/join.sql | 23 +++++++++++++++++++
2 files changed, 53 insertions(+), 6 deletions(-)
diff --git a/src/backend/rewrite/rewriteManip.c b/src/backend/rewrite/rewriteManip.c
index 9c9d1cad33b..3e85b38cecb 100644
--- a/src/backend/rewrite/rewriteManip.c
+++ b/src/backend/rewrite/rewriteManip.c
@@ -23,6 +23,7 @@
#include "parser/parse_relation.h"
#include "parser/parsetree.h"
#include "rewrite/rewriteManip.h"
+#include "optimizer/clauses.h"
#include "utils/lsyscache.h"
@@ -1369,17 +1370,17 @@ remove_nulling_relids_mutator(Node *node,
if (phv->phlevelsup == context->sublevels_up &&
!bms_overlap(phv->phrels, context->except_relids))
{
- /*
- * Note: it might seem desirable to remove the PHV altogether if
- * phnullingrels goes to empty. Currently we dare not do that
- * because we use PHVs in some cases to enforce separate identity
- * of subexpressions; see wrap_option usages in prepjointree.c.
- */
+ int orig_size;
+ int size;
+
/* Copy the PlaceHolderVar and mutate what's below ... */
phv = (PlaceHolderVar *)
expression_tree_mutator(node,
remove_nulling_relids_mutator,
context);
+
+ orig_size = bms_num_members(phv->phnullingrels);
+
/* ... and replace the copy's phnullingrels field */
phv->phnullingrels = bms_difference(phv->phnullingrels,
context->removable_relids);
@@ -1387,6 +1388,29 @@ remove_nulling_relids_mutator(Node *node,
phv->phrels = bms_difference(phv->phrels,
context->removable_relids);
Assert(!bms_is_empty(phv->phrels));
+
+ size = bms_num_members(phv->phnullingrels);
+
+ /*
+ * Note: it might seem desirable to remove the PHV altogether if
+ * phnullingrels goes to empty. Currently we dare not do that
+ * because we use PHVs in some cases to enforce separate identity
+ * of subexpressions; see wrap_option usages in prepjointree.c.
+ *
+ * However, if the PHV was previously nullable but now has no nulling
+ * relations, and its inner expression is pseudo-constant, it has
+ * effectively become a constant. We can dissolve it immediately
+ * by returning the inner expression.
+ *
+ * TODO : Check and confirm if there are any cases where this also might be wrong.
+ */
+ if (orig_size > 0 &&
+ size == 0 &&
+ is_pseudo_constant_clause((Node *) phv->phexpr))
+ {
+ return (Node *) phv->phexpr;
+ }
+
return (Node *) phv;
}
/* Otherwise fall through to copy the PlaceHolderVar normally */
diff --git a/src/test/regress/sql/join.sql b/src/test/regress/sql/join.sql
index 85aed7bf704..a61ef6e4958 100644
--- a/src/test/regress/sql/join.sql
+++ b/src/test/regress/sql/join.sql
@@ -3920,3 +3920,26 @@ SELECT COUNT(*) FROM onek t1 LEFT JOIN tenk1 t2
ON (t2.thousand = t1.tenthous OR t2.thousand = t1.thousand);
SELECT COUNT(*) FROM onek t1 LEFT JOIN tenk1 t2
ON (t2.thousand = t1.tenthous OR t2.thousand = t1.thousand);
+
+-- Test Bug 19560 (loss of qual after join removal)
+CREATE TEMP TABLE bug_19560_items (id text, owner text);
+CREATE TEMP TABLE bug_19560_follows (item_id text, user_id text, UNIQUE (user_id, item_id));
+INSERT INTO bug_19560_items VALUES ('1', 'alice');
+INSERT INTO bug_19560_follows VALUES ('1', 'bob');
+
+-- should return 0
+SELECT COUNT(*)
+FROM bug_19560_items items
+LEFT JOIN bug_19560_follows follows ON follows.item_id = items.id AND follows.user_id = 'bob'
+LEFT JOIN (SELECT 'bob' AS id) viewer ON TRUE
+WHERE items.owner = viewer.id;
+
+-- explain should show the filter items.owner = 'bob'
+EXPLAIN (COSTS OFF)
+SELECT COUNT(*)
+FROM bug_19560_items items
+LEFT JOIN bug_19560_follows follows ON follows.item_id = items.id AND follows.user_id = 'bob'
+LEFT JOIN (SELECT 'bob' AS id) viewer ON TRUE
+WHERE items.owner = viewer.id;
+
+DROP TABLE bug_19560_items, bug_19560_follows;
--
2.55.0.229.g6434b31f56-goog
^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2026-07-24 16:50 UTC | newest]
Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2010-01-13 09:02 Substring auto trim Charles O'Farrell <charleso@gmail.com>
2010-01-13 13:36 ` Pavel Stehule <pavel.stehule@gmail.com>
2010-01-13 13:55 ` Pavel Stehule <pavel.stehule@gmail.com>
2010-01-13 15:35 ` Tom Lane <tgl@sss.pgh.pa.us>
2010-01-13 16:01 ` Kevin Grittner <Kevin.Grittner@wicourts.gov>
2010-01-13 17:14 ` Tom Lane <tgl@sss.pgh.pa.us>
2010-01-13 17:21 ` Kevin Grittner <Kevin.Grittner@wicourts.gov>
2010-01-13 22:20 ` Charles O'Farrell <charleso@gmail.com>
2026-07-20 09:44 BUG #19560: Wrong results since v16: removable LEFT JOIN silently drops WHERE qual PG Bug reporting form <noreply@postgresql.org>
2026-07-24 16:50 ` Re: BUG #19560: Wrong results since v16: removable LEFT JOIN silently drops WHERE qual Nitin Motiani <nitinmotiani@google.com>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox