On 07/29/19 18:27, Alexander Korotkov wrote:
> What do you think about renaming existing operator from like_regex to
> pg_like_regex? Or introducing special flag indicating that PostgreSQL
> regex engine is used ('p' for instance)?
Renaming the operator is simple and certainly solves the problem.
I don't have a strong technical argument for or against any of:
$.** ? (@ pg_like_regex "O(w|v)" flag "i")
$.** ? (@ pg_like_regex "O(w|v)")
$.** ? (@ like_regex "O(w|v)" pg flag "i")
$.** ? (@ like_regex "O(w|v)" pg)
$.** ? (@ like_regex "O(w|v)" flag "ip")
$.** ? (@ like_regex "O(w|v)" flag "p")
It seems more of an aesthetic judgment (on which I am no particular
authority).
I think I would be -0.3 on the third approach just because of the need
to still spell out ' flag "p"' when there is no other flag you want.
I assume the first two approaches would be about equally easy to
implement, assuming there's a parser that already has an optional
production for "flag" STRING.
Both of the first two seem pretty safe from colliding with a
future addition to the standard.
To my aesthetic sense, pg_like_regex feels like "another operator
to remember" while like_regex ... pg feels like "ok, a slight variant
on the operator from the spec".
Later on, if a conformant version is added, the grammar might be a bit
simpler with just one name and an optional pg.
Going with a flag, there is some question of the likelihood of
the chosen flag letter being usurped by the standard at some point.
I'm leaning toward a flag for now in my own effort to provide the five SQL
functions (like_regex, occurrences_regex, position_regex, substring_regex,
and translate_regex), as for the time being it will be as an extension,
so no custom grammar for me, and I don't really want to make five
pg_* variant function names, and have that expand to ten function names
someday if the real ones are implemented. (Hmm, I suppose I could add
an optional function argument, distinct from flags; that would be
analogous to adding a pg in the grammar ... avoids overloading the flags,
avoids renaming the functions.)
I see in the Saxon library there is already a convention where it
allows a few flags undefined by the standard, after a semicolon in the
flag string. That has no official status; the XQuery spec
defines [smixq] and requires an error for anything else. But it
does have the advantage that the flag string can just be chopped
at the semicolon to eliminate all but the standard flags, and the
advantage (?) that at least one thing is already doing it.
Regards,
-Chap