Re: proposal: plpgsql - Assert statement

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Marko Tiikkaja <marko(at)joh(dot)to>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: plpgsql - Assert statement
Date: 2014-11-23 21:40:30
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

I wrote:
> The core of that complaint is that we'd have to make ASSERT a plpgsql
> reserved word, which is true enough as things stand today. However,
> why is it that plpgsql statement-introducing keywords need to be
> reserved? The only reason for that AFAICS is to allow us to distinguish
> the statements from assignments. But it seems like that could possibly
> be gotten around with some work.

Attached is a draft patch that de-reserves 17 of plpgsql's existing
reserved words, leaving 24 still reserved (of which only 9 are not also
reserved in the core grammar). This would make it painless to invent an
ASSERT statement, as well as any other new statement type that's not
associated with looping or block structure. (The limiting factor on those
is that if a statement could have an opt_block_label, its keyword still
has to be reserved, unless we want to complicate matters a bunch more.)

regards, tom lane

Attachment Content-Type Size
plpgsql-fewer-reserved-words.patch text/x-diff 15.1 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-11-23 23:59:24 Re: group locking: incomplete patch, just for discussion
Previous Message Andres Freund 2014-11-23 20:38:56 Re: superuser() shortcuts