Re: Outputting Standard SQL

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

In response to

Browse pgsql-hackers by date

  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)