Re: PostgreSQL vs SQL Standard

On Sat, Jun 9, 2018 at 8:37 PM, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
wrote:
> I think I got all the issues I currently know of, but there may be
> more, and others may disagree with my classification of issues or the
> rationales for violating the spec. Any feedback?

Related to, but I think distinct from

"Trailing spaces in character(n)"
Trailing spaces in char(n) values are removed in contexts where the
spec requires they be kept.

E021-03 Character literals subclause 5.3, "<literal>": <quote> [ <character
representation>... ] <quote>

In subclause 5.3 (SQL standard 2011 part 2: foundation), <character string
literal> is defined (ignoring
the character set specifier and the weird multi-line continuations) as

<character string literal> ::= <quote> [ <character representation>...
] <quote>

syntax rule 17 states

"The declared type of a <character string literal> is fixed-length
character string."

In PostgreSQL, the same syntax (<quote> [ <character representation>... ]
<quote>) is a string constant and in
the PostgreSQL documentation, section 4.1.2 constants, it says that string
constants are one
of the three kinds of implicitly typed constants.

Where you see the difference is that trailing spaces in a string constant
are retained when the type
is resolved to text, but if the constant was typed as bpchar and then cast
to text, the trailing spaces
would be trimmed.

https://www.postgresql.org/message-id/28069.1501269327%40sss.pgh.pa.us
https://www.postgresql.org/message-id/9524.1511311751%40sss.pgh.pa.us

You also see that the type of a string constant is implicit in cases where
PostgreSQL is
unable to determine the type of a string constant from its context.

https://www.postgresql.org/message-id/1405965382386-5812247.post%40n5.nabble.com

I could be reading some of this incorrectly, but putting it all together,
it looks to me like
PostgreSQL does not meet a strict interpretation of E021-03.

I'd put it in the WONTFIX section.