If we're going to create a brand new language then I think it would be extremely foolish to keep *any* of the current pain points around. Off the top of my head:
- variables must have an identifier (what $ in most languages does). The steps you have to go through to avoid simple naming collisions are insane.
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.
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.
- 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.
