On Thu, Sep 4, 2014 at 4:06 AM, Joel Jacobson <joel@trustly.com> wrote:
> Your "ASSERT CHECK ROWCOUNT = 1;" is lengthly, which is why I don't like it.
> Imagine if having to type
> my $var =========================== 'foo';
> instead of
> my $var = 'foo';
> on every single line of could where you want to assign a variable,
> that would just be ridiculous.
This is really the core of the problem. PL/pgsql is an incredibly
verbose language, and things that ought to be expressable in a small
number of characters often take a large number of characters. The
reason this problem is hard to solve is that PL/pgsql is based on SQL,
and SQL is inherently pretty verbose. When we try to extend PL/pgsql,
we can either pick syntax that looks like the existing language (which
sucks because it's verbose) or we can pick syntax that is compact
(which sucks because it looks nothing like the rest of the language).
This is a deep and fundamental conflict that is not going away.
So I'm with the crowd of people who says there's really nothing that
can be done to improve PL/pgsql much. Yeah, we could make certain
cases a little better at the expense of certain other cases (which is
how this thread got started), but it's not really clear that we'd end
up ahead at all (since a lot of people objected to the proposed
changes) and if we did we wouldn't end up very far ahead (since the
original proposal consisted of three minor items which are not going
to radically transform anyone's experience). Even Oracle, who has a
vastly larger R&D budget than the PostgreSQL community, frankly hasn't
done all that much with it. They have some nice conveniences which we
lack, but it's still a clunky language.
So, I think the right solution here is to work on improving the user
experience people have with other procedural languages. Perl, Python,
and Javascript are all notable for being terse, sometimes to excess.
I remember trying to use PL/perl many years ago and giving up on it
because of various problems, like not being able to get "require" to
work, and not being able to create helper functions that could be
called directly from Perl without going back through the SQL layer.
But some of those kinds of things may have been fixed between then and
now, and whichever ones haven't probably can be if people are willing
to put in some work.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
