2014-11-19 23:54 GMT+01:00 Tom Lane <t...@sss.pgh.pa.us>: > Marko Tiikkaja <ma...@joh.to> writes: > > I also went back to the original thread, and I think Heikki's summary > > dismissed e.g. Robert's criticism quite lightly: > > > http://www.postgresql.org/message-id/ca+tgmobwossrncv_ijk3xhsytxb7dv0awgvwkmeurntovez...@mail.gmail.com > > 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. The first thing that comes to mind is > for the lexer to do one-token lookahead and assume that the second > token of an assignment must be ":=" (aka "="), ".", or "[". (Have > I missed any cases?) Then, any statement for which the second token > can't be one of those, which is surely most if not all of them, could > have an unreserved leading keyword. This would at a stroke dereserve > about half of plpgsql's existing reserved words, as well as remove a > roadblock for ASSERT and other new statements. >
Doesn't it close a doors to implement a procedures call without explicit CALL statement (like PL/SQL) ? Personally I doesn't feel to introduce lot of new keywords (statements) to plpgsql. Probably only two - ASSERT (assertions), PRAGMA (some cooperation with plpgsql extensions). > > regards, tom lane >
