[jira] [Commented] (CALCITE-5305) Character literals with C-style escapes

["Dmitry Sysolyatin (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CALCITE-5305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17620158#comment-17620158 ] 

Dmitry Sysolyatin commented on CALCITE-5305:
--------------------------------------------

[~julianhyde] Your changes looks good. Thanks for helping.

> Character literals with C-style escapes
> ---------------------------------------
>
>                 Key: CALCITE-5305
>                 URL: https://issues.apache.org/jira/browse/CALCITE-5305
>             Project: Calcite
>          Issue Type: Improvement
>          Components: core
>            Reporter: Dmitry Sysolyatin
>            Assignee: Dmitry Sysolyatin
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 1.33.0
>
>
> Support string constants with c-style escapes. Example:
> {code:java}
> select e'\u0061\x61\141' as col1;
>  col1 
> ------
>  aaa
> (1 row)
> {code}
> From PostgreSQL documentation [4.1.2.2. String Constants With C-Style Escapes|https://www.postgresql.org/docs/14/sql-syntax-lexical.html#SQL-SYNTAX-CONSTANTS]:
> An escape string constant is specified by writing the letter {{E}} (upper or lower case) just before the opening single quote, e.g., {{{}E'foo'{}}}. (When continuing an escape string constant across lines, write {{E}} only before the first opening quote.) Within an escape string, a backslash character (\) begins a C-like _backslash escape_ sequence, in which the combination of backslash and following character(s) represent a special byte value, as shown in Table:
> ||Backslash Escape Sequence||Interpretation||
> |\b|backspace|
> |\f|form feed|
> |\n|newline|
> |\r|carriage return|
> |\t|tab|
> |\o, \oo, \ooo (o = 0–7)|octal byte value|
> |\xh, \xhh (h = 0–9, A–F)|hexadecimal byte value|
> |\uxxxx, \Uxxxxxxxx (x = 0–9, A–F)|16 or 32-bit hexadecimal Unicode character value|
> I suggest to not introduce any configuration flags for this feature because it seems like it does not contradict with any SQL dialect and it shouldn't slow down queries parsing.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)