Feedback-ID: ia2694551:Fastmail
Date: Tue, 18 Jun 2024 11:33:25 +0200
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: voronaam@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18510: jsonpath does not support trailing backslash at the
 end of the query
Message-ID: <202406180933.az7sf7jc74ny@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAKFQuwa+MmScFnf=hNyUih2O0LkKgDw2uy39Ff0870zgP3v72Q@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/202406180933.az7sf7jc74ny%40alvherre.pgsql>
Precedence: bulk

On 2024-Jun-14, David G. Johnston wrote:

> It is working just fine.  It sees both the regex and the backslash
> character and then helpfully tells you that the regex you wrote is
> bogus since the backslash you wrote isn't escaping anything.

Not really connected to this bug, but I think we should get rid of the
error that says that the end backslashes are useless.  If that error
wasn't there, we would be one step closer to being able to mark the
operator for LIKE as leakproof.  Right now, if you mark that operator as
leakproof and use it in a security barrier view, attackers can leak
entire strings by testing with that operator for each character one at a
time.

=# select * from secret where data like substring(data, 1, 7) escape 'r';
ERROR:  LIKE pattern must not end with escape character

Here I verify that the character number 7 is an 'r'.

So this one error is the sole reason we have to mark the LIKE operator
as leaky, which is sad.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"Just treat us the way you want to be treated + some extra allowance
 for ignorance."                                    (Michael Brusser)