Re: BUG #14512: Backslashes in LIKE

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Vojtěch Rylko <vojta(dot)rylko(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #14512: Backslashes in LIKE
Date: 2017-01-25 15:11:15
Message-ID: CAKFQuwY5teVM4aF9mnoMXuv1k=66tKRkPtSBAJeWMdmxLCe0jA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Wed, Jan 25, 2017 at 2:16 AM, Vojtěch Rylko <vojta(dot)rylko(at)gmail(dot)com>
wrote:

> 2017-01-24 19:15 GMT+01:00 David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)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.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message John McKown 2017-01-25 15:23:53 Re: BUG #14514: Bug in Subquery
Previous Message Fabien COELHO 2017-01-25 14:25:07 Re: Problem in using pgbench's --connect(-C) and --rate=rate(-R rate) options together.