Re: Outputting Standard SQL

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

In response to

Responses

Browse pgsql-hackers by date

  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