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.
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. |