On 1/9/17 5:30 PM, Marko Tiikkaja wrote:
This is exactly what we did not want to do with this project. The idea
is to create a language which is really close to PL/PgSQL, but removes
some of the brain diarrhoea currently present.
As a general comment, ISTM it'd be much better to do as much as we can
in the current language then. It's going to take a LOT to get people to
switch to a different language, so there needs to be a LOT of added value.
Now, this *is* a problem, and the solution we had (well I, mostly, at
this point) in mind is to use the underscore prefix for all input
variables and make OUT parameters invisible to queries inside function
bodies unless explicitly prefixed with OUT. As far as I can tell this
eliminates most if not all collisions while staying almost completely
compatible with arguably well-written PL/PgSQL 1.
That might be workable... it's still rather ugly though.
I don't see prefixing everything with _ as being useful though; people
can already do that if they want to uglify the function's argument names.
I do think there's stuff that could be done along these lines with
namespaces though. Allowing users to rename the namespace that arguments
went into would be a huge step forward. I think having a separate
namespace for all the automatic variables would be a big help too.
Amusingly, that would allow users to set the namespace to '$', which
would (almost) give you $variable.
- Support for the notion of a variable being unset (which is NOT the
same thing as NULL).
My idea was that the currently unsupported combination of NOT NULL and
no DEFAULT would mean "has to be assigned to a non-NULL value before it
can be read from, or an exception is thrown". Solves the most common
use case and is backwards compatible.
That won't allow you to use a variable in multiple places though... is
there a reason we couldn't support something like IS DEFINED and UNSET?
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
