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

Поиск
Список
Период
Сортировка
От Bryn Llewellyn
Тема Re: Surprisingly forgiving behavior when a case expression is terminated with "end case"
Дата
Msg-id 9F2C5B40-033B-4120-836B-3B42FAA5679B@yugabyte.com
обсуждение исходный текст
Ответ на Re: Surprisingly forgiving behavior when a case expression is terminated with "end case"  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
I think we've spent a great deal of blood, sweat, and tears making that so, or as nearly so as we could. We will in fact take any keyword after "AS", and in recent versions many non-reserved keywords will work that way without "AS".

(Mind you, I think the SQL spec made a serious design error in allowing "AS" to be optional. But we have to live with that as best we can.)


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):

Thank you both. I never would have guessed that a word with "reserved" status could be used as a column alias (with or without preceding it with AS). "not completely reserved in PostgreSQL" makes this sound like a PG special.

So I was caught out yet again. And I fear that I'll continue to be caught out with other things—and maybe this one too, at some later date, when I've forgotten the present exchanges…

Anyway, I believe that I have the answer to my question. And my new mental model allowed me to predict that, as presented, this would work:

create function f()
  returns text
  language plpgsql
as $body$
declare
  a constant int := 3;
  b constant int := 5;
  c constant int := 7;
begin
  return a + b case /* + c */;
end;
$body$;

select f();

It does! It predicted, too, that when "+ c" is uncommented, "create function" would fail with a syntax error. And that prediction also held out.

В списке pgsql-general по дате отправления:

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: Why is DEFAULT much faster than UPDATE?
Следующее
От: Bryn Llewellyn
Дата:
Сообщение: Surprising results from current_role in a "security invoker" trigger function in a "cascade delete via FK" scenario