From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Outputting Standard SQL |
Date: | 2019-08-25 19:14:46 |
Message-ID: | 30913.1566760486@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com> writes:
> EXPLAIN (COSTS OFF) SELECT * FROM pg_am WHERE amname LIKE '%t%';
> QUERY PLAN
> -----------------------------------
> Seq Scan on pg_am
> Filter: (amname ~~ '%t%'::text)
> (2 rows)
> Why don't we convert that back to LIKE?
Trying to do so would make our schema-qualification problems worse
not better. See
https://www.postgresql.org/message-id/flat/ffefc172-a487-aa87-a0e7-472bf29735c8%40gmail.com
particularly
https://www.postgresql.org/message-id/10492.1531515255@sss.pgh.pa.us
We really need to invent some weird nonstandard syntax for IS DISTINCT
FROM and related cases, in order to not have broken dump/reload scenarios.
I'd just as soon not do that for LIKE, when the operator syntax serves
well enough.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Quentin Rameau | 2019-08-25 19:21:36 | Re: [PATCH] Fix missing argument handling in psql getopt |
Previous Message | Quentin Rameau | 2019-08-25 19:00:09 | Re: [PATCH] Fix missing argument handling in psql getopt |