On 2013-09-14 22:24, Pavel Stehule wrote:
There is a significant issue - new reserved keyword. There is high probability so lot of users has a functions named "assert".
Someone may prove me wrong here, but to me it looks like this would only prevent ASSERT from being used as the name of a PL/PgSQL variable. That's still a backwards compatibility break, but the case you were worried about should still work:
=# create function assert(boolean) returns boolean as $$ begin if $1 is not true then raise exception 'custom assert()'; end if; return true; end $$ language plpgsql;
CREATE FUNCTION =# create function f() returns int as $$ $# begin $# assert false; $# perform assert(true); $# if assert(true) then $# perform assert(false); $# end if; $# end $# $$ language plpgsql; CREATE FUNCTION =# select f(); ERROR: custom assert() CONTEXT: SQL statement "SELECT assert(false)" PL/pgSQL function f() line 6 at PERFORM
I like this functionality, but I dislike any compatibility break for feature, that can be implemented as extension without any lost of compatibility or lost of functionality.
I don't see how this could be implemented as an extension, even if you write it in C. I think being able to turn assertions off in production with no execution time overhead is what justifies having this in-core. The nicer syntax isn't enough (compared to, say, PERFORM assert(..)). And if we're only breaking code for people who use "assert" as the variable name, I'd say we go for it.
So can you redesign this without new keyword?
I don't see an easy way to do that, but I'm not too familiar with PL/PgSQL's parser so maybe I'm just missing something.
Regards, Marko Tiikkaja -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
