Incorrect extraction of parameter placeholder positions

[pestaa]

Bug Report

Q	A
BC Break	no
Version	2.9.2

Summary

SQLParserUtils::expandListParameters() and getPlaceholderPositions() fails to produce fragments when the quoted string '[]' appears in the query.

Current behaviour

The named parameters are located before the problematic cut, but not after. Leaving a mix of positional and named parameters is rejected by the driver.

How to reproduce

Postgres-specific range functions receive a third parameter, describing the inclusiveness of the range.

SELECT daterange('2000-01-01', now(), '[]') AS x, :named_parameter AS y

It somehow matches as an opening of a bracket quoted text, cutting the rest of the statement from the fragment before locating named parameters.

The "bracket quoted text" regex fragment seems to be the latest addition (judging by the order of the constants and that it's the only private one), so I suspect it is too eager to parse such brackets inside other quoted literals.

I've briefly looked into the development of 3.0, but the proper SQL parsing facilities are not yet put into place to mitigate this (the methods in question are marked as deprecated though).

Workaround

Providing '[]' as a named parameter, such as :inclusive, gets around the limitation.

[morozov]

This must be irrelevant as of #4397. Please let us know if it still is.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.