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
