Chris McDonald <chrisjonmcdonald@xxxxxxxxx> writes:
> Hi, I am upgrading a system from postgresql 8.4.8 (fedora 13 x64) to
> postgresql 9.0.5 (fedora 15 x64). As I build a database I've noticed
> that the following works on 8.4.8 but does not work on 9.0.5. Can
> someone tell me why this is not legal syntax in 9.0.5 but is legal
> in 8.4.8 please:
>
> ===snip===
> create type mytype
> as
> (
> somekey integer,
> open numeric(14, 2)
> );
>
> CREATE OR REPLACE FUNCTION myfunc(IN INTEGER, IN NUMERIC(14, 2))
> RETURNS VOID
> AS $$
> DECLARE
> somekey ALIAS FOR $1;
> rec mytype;
> BEGIN
> rec.somekey = somekey;
>
> -- 9.0.5 will fail at the dot character in the
> -- following line here with syntax error sqlstate 42601
> -- but 8.4.8 is happy.
> rec.open = 32;
I wonder if this remark in the release notes is relevant. Tom will
probably shed some light here. I don't get the connection but we'll
see.
* Improve handling of cases where PL/pgSQL variable names conflict with identifiers used in queries within a
function (Tom Lane)
The default behavior is now to throw an error when there is a conflict, so as to avoid surprising behaviors. This
can be modified, via the configuration parameter plpgsql.variable_conflict or the per-function option #
variable_conflict, to allow either the variable or the query-supplied column to be used. In any case PL/pgSQL will
no longer attempt to substitute variables in places where they would not be syntactically valid.
>
> RETURN;
> END;
> $$ LANGUAGE plpgsql;
> ===snip===
>
> --
> Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
--
Jerry Sievers
Postgres DBA/Development Consulting
e: postgres.consulting@xxxxxxxxxxx
p: 305.321.1144
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
