Re: Outputting Standard SQL - Mailing list pgsql-hackers

From Vik Fearing
Subject Re: Outputting Standard SQL
Date
Msg-id c1953674-4a58-4fd4-c440-726906154cd2@2ndquadrant.com
Whole thread Raw
In response to Re: Outputting Standard SQL  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 25/08/2019 21:14, Tom Lane wrote:
> Vik Fearing <vik.fearing@2ndquadrant.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




pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: pg11.5: ExecHashJoinNewBatch: glibc detected...double free orcorruption (!prev)
Next
From: Justin Pryzby
Date:
Subject: Re: pg11.5: ExecHashJoinNewBatch: glibc detected...double free orcorruption (!prev)