Alvaro Herrera from 2ndQuadrant writes:
> Marked ready for committer.
Thanks for reviewing. I adopted your doc change suggestions
and pushed it.
regards, tom lane
On 2019-May-23, Tom Lane wrote:
> +
> +Another nonstandard extension is that following the escape character
> +with a letter or digit provides access to the same escape sequences
> +defined for POSIX regular expressions, below (see
> +,
> +, and
> +).
>
I think the
> "Tom" == Tom Lane writes:
> Alvaro Herrera from 2ndQuadrant writes:
>> This discussion seems to have died down. Apparently we have three
>> directions here, from three different people. Are we doing anything?
Tom> I don't really want to do anything beyond the patch I submitted in
T
Alvaro Herrera from 2ndQuadrant writes:
> This discussion seems to have died down. Apparently we have three
> directions here, from three different people. Are we doing anything?
I don't really want to do anything beyond the patch I submitted in
this thread (at <32617.1558649...@sss.pgh.pa.us>)
This discussion seems to have died down. Apparently we have three
directions here, from three different people. Are we doing anything?
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
I wrote:
> I propose therefore that we leave similar_escape in place with its
> current behavior, as a compatibility measure for cases like this.
> Intead, invent two new strict functions, say
> similar_to_escape(pattern)
> similar_to_escape(pattern, escape)
> and change the parser and
> "Robert" == Robert Haas writes:
Robert> But the number of people using out-of-core postfix operators
Robert> has got to be really tiny -- unless, maybe, there's some really
Robert> popular extension like PostGIS that uses them.
If there's any extension that uses them I've so far failed
Robert Haas writes:
> I think it's pretty clear that the theoretical beauty of being able to
> handle postfix operators is not worth the tangible cost they impose on
> our parser. We're losing more users as a result of SQL that other
> systems can accept and we cannot than we are gaining by being
On Mon, May 13, 2019 at 2:39 PM Andrew Gierth
wrote:
> Or we could kill off postfix operators...
/me helps Andrew hijack the thread.
We wouldn't even have to go that far. We could just restrict it to a
specific list of operators that are hard-coded into the lexer and
parser, like say only '!'.
[ backing up to a different sub-discussion ]
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> To support the first usage, similar_escape is non-strict, and it
> Tom> takes a NULL second argument to mean '\'. This is already a SQL
> Tom> spec violation, because as far as I can tell fro
> "Tom" == Tom Lane writes:
Tom> Hmm. Oddly, you can't fix it by adding parens:
Tom> regression=# select 'foo' similar to ('f' || escape) escape escape from
(values ('oo')) v(escape);
Tom> psql: ERROR: syntax error at or near "escape"
Tom> LINE 1: select 'foo' similar to ('f' || escap
Andrew Gierth writes:
> "Andrew" == Andrew Gierth writes:
> Andrew> The ESCAPE part could in theory be ambiguous if the SIMILAR
> Andrew> expression ends in a ... SIMILAR TO xxx operator, since then we
> Andrew> wouldn't know whether to attach the ESCAPE to that or keep it
> Andrew> as part o
> "Andrew" == Andrew Gierth writes:
Andrew> The ESCAPE part could in theory be ambiguous if the SIMILAR
Andrew> expression ends in a ... SIMILAR TO xxx operator, since then we
Andrew> wouldn't know whether to attach the ESCAPE to that or keep it
Andrew> as part of the function syntax. But
> "Andrew" == Andrew Gierth writes:
Tom> I am, frankly, inclined to ignore this as a bad idea. We do have
Tom> SIMILAR and ESCAPE as keywords already, but they're
Tom> type_func_name_keyword and unreserved_keyword respectively. To
Tom> support this syntax, I'm pretty sure we'd have to mak
> "Tom" == Tom Lane writes:
Tom> but in recent versions it's
Tom> ::=
Tom> SUBSTRING
Tom> SIMILAR
Tom> ESCAPE
Tom> I am, frankly, inclined to ignore this as a bad idea. We do have
To
Over in pgsql-bugs [1], we're looking into some bugs associated with
mistranslation of SQL-spec regexes to POSIX regexes. However, while
poking at that I couldn't help noticing that there are more ways in
which we're not following the letter of the SQL spec in this area:
* As Andrew noted, somewh
16 matches
Mail list logo
