Re: [BUGS] BUG #14512: Backslashes in LIKE - Mailing list pgsql-bugs

From David G. Johnston
Subject Re: [BUGS] BUG #14512: Backslashes in LIKE
Date
Msg-id CAKFQuwY5teVM4aF9mnoMXuv1k=66tKRkPtSBAJeWMdmxLCe0jA@mail.gmail.com
Whole thread Raw
In response to Re: [BUGS] BUG #14512: Backslashes in LIKE  (Vojtěch Rylko <vojta.rylko@gmail.com>)
List pgsql-bugs
On Wed, Jan 25, 2017 at 2:16 AM, Vojtěch Rylko <vojta.rylko@gmail.com> wrote:
2017-01-24 19:15 GMT+01:00 David G. Johnston <david.g.johnston@gmail.com>:
>
> Then consider a feature request that a malformed pattern be detected and fail independent of the data being checked. Such non-deterministic failure is at least a POLA violation and makes what should be a basically compile-time error into a run-time one.

This is not pure compile-time "error" as pattern in LIKE could be
dynamic expression, for example:

But now we're no longer talking about an expression of the form "LIKE constant".  In SQL whenever you decide to write a query that involves tables and columns you run the risk of introducing run-time bugs if you make assumptions about the contents of those columns that fail to hold.  So if you decide to write queries of that form you should define table t like so:

create table t (a varchar check (a !~ '\$')) -- which could be improved upon depending on your needs - but it would at least catch every actual invalid expression at the cost of disallowing valid ones.

David J.

pgsql-bugs by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: [BUGS] Problem in using pgbench's --connect(-C) and --rate=rate(-Rrate) options together.
Next
From: John McKown
Date:
Subject: Re: [BUGS] BUG #14514: Bug in Subquery