Обсуждение: Outputting Standard SQL
This is a minor gripe in the grand scheme of things, but I'm a little annoyed that we accept standard SQL but then don't spit it back out. For example: ``` 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? Sure, if someone actually typed "~~" instead of "LIKE" then that wouldn't match what they wrote, but I much prefer differing in that direction than the current one. I am not advocating we attempt anything more complex such as "x ~>=~ 'y' AND x ~<~ 'z'", just that we output SQL where feasible. I would like to fiddle with this if there is consensus that a decent patch would be accepted. -- Vik Fearing
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 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
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