Re: Surprisingly forgiving behavior when a case expression is terminated with "end case"

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: Bryn Llewellyn <bryn(at)yugabyte(dot)com>, pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Surprisingly forgiving behavior when a case expression is terminated with "end case"
Date: 2022-08-10 19:18:25
Message-ID: 6aa4cba7-6d45-fc05-219c-72632b4b423f@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 8/10/22 11:59, Bryn Llewellyn wrote:
> The account of the CASE expression here:
>
> https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-CASE
> <https://www.postgresql.org/docs/current/functions-conditional.html#FUNCTIONS-CASE>
>
> says that it's terminated with the keyword END (just as I've always
> understood)—i.e. not with the PL/pgSQL CASE statement's  END CASE.
>
> Moreover CASE is a reserved word—as a "create table case(…)" attempt
> shows. Yet CASE is tolerated (using PG 14.4) here:
>
> *select 1 as case;
> *
> In fact, any reserved word that I try (like IF, THEN, and so on) is
> accepted as an alias. This seems to me to be wrong. What do you (all) think?

But documented:

https://www.postgresql.org/docs/current/sql-keywords-appendix.html

" Even reserved key words are not completely reserved in PostgreSQL, but
can be used as column labels (for example, SELECT 55 AS CHECK, even
though CHECK is a reserved key word)."

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message André Hänsel 2022-08-10 23:02:13 Why is DEFAULT much faster than UPDATE?
Previous Message Tom Lane 2022-08-10 19:17:53 Re: Surprisingly forgiving behavior when a case expression is terminated with "end case"