On Thu, Sep 4, 2014 at 4:06 AM, Joel Jacobson <j...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
