Pavel's personal requirements include that it be well suited for
static analysis of plpgsql using his plpgsql_check tool. So he wants
persistent definitions.
I've been in static analysis for the last 25 years, and the logic of this
statement fails me.
Pavel wants that the plpgsql_check tool can statically analyse session
variables, which is fine with me.
It does not fellow that the definition must be "persistent" as such, it
fellows that it should be available in the PL/pgSQL script so that a tool
which reads it can check it by looking at the codes. IMO this is a lesser
requirement.
I do not think that a feature should be designed around the current
limitations of a particular external tool, esp. if said tool can be
improved at a reasonable cost.
I think progress can only be achieved by setting out requirements, a
feature matrix, and which proposed implementations can deliver which
desired features. Then go from there.
Yep. I've bootstapped a wiki page, feel free to improve it as you see fit:
https://wiki.postgresql.org/wiki/Variable_Design
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
