> IIRC the original complaint was from someone trying to migrate code
> from T/SQL or some other not-quite-PLSQL language. Like you, I'm on
> the fence about whether to accept this patch, but it does have some
> in-migration rationale.
As someone who writes a lot of plpgsql, I'm in favor of the patch.
1. Compatibility with PL/SQL, especially in the extra features
direction, has never been a tremendous priority for us before;
2. We don't particularly care if native plpgsql procedures can be
back-ported to PLSQL, and if we did there are much greater compatibility
issues than this one;
3. This patch eliminates a common plpgsql beginner error and saves all
of us heavy plpgsql users some typing, especially when the use of a
mutable variable means that we can eliminate the DECLARE section
entirely, as in:
This:
CREATE PROCEDURE mod ( x int, y int )
RETURNS int LANGUAGE plpgsql
AS $f$
DECLARE
z INT := x;
BEGIN
z := x % y;
RETURN z;
END; $f$
Becomes this:
CREATE PROCEDURE mod ( x int, y int )
RETURNS int LANGUAGE plpgsql
AS $f$
BEGIN
x := x % y;
RETURN x;
END; $f$
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
