Re: [BUGS] BUG #14512: Backslashes in LIKE

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: [BUGS] BUG #14512: Backslashes in LIKE
Дата
Msg-id CAKFQuwY5teVM4aF9mnoMXuv1k=66tKRkPtSBAJeWMdmxLCe0jA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [BUGS] BUG #14512: Backslashes in LIKE  (Vojtěch Rylko <vojta.rylko@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: [BUGS] Problem in using pgbench's --connect(-C) and --rate=rate(-Rrate) options together.
Следующее
От: John McKown
Дата:
Сообщение: Re: [BUGS] BUG #14514: Bug in Subquery