From: | Vik Fearing <vik(dot)fearing(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Outputting Standard SQL |
Date: | 2019-08-26 02:43:52 |
Message-ID: | c1953674-4a58-4fd4-c440-726906154cd2@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 25/08/2019 21:14, Tom Lane wrote:
> 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
Oh, okay, that makes sense. Unfortunately.
> 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.
LIKE was just an example among many others.
--
Vik Fearing
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2019-08-26 02:54:21 | Re: pg11.5: ExecHashJoinNewBatch: glibc detected...double free or corruption (!prev) |
Previous Message | Thomas Munro | 2019-08-26 02:34:31 | Re: pg11.5: ExecHashJoinNewBatch: glibc detected...double free or corruption (!prev) |