Re: [HACKERS] merging some features from plpgsql2 project - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: [HACKERS] merging some features from plpgsql2 project
Date
Msg-id CAHyXU0wpOjWDmiNAVydfTxZ2=YGxT3KrttchGnFQmhfLBygRow@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] merging some features from plpgsql2 project  (Marko Tiikkaja <marko@joh.to>)
Responses Re: [HACKERS] merging some features from plpgsql2 project  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
On Tue, Jan 10, 2017 at 7:44 AM, Marko Tiikkaja <marko@joh.to> wrote:
> On Tue, Jan 10, 2017 at 2:26 PM, Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> wrote:
>>
>> It's not like PL/pgSQL is the king of brevity.
>
>
> This is essentially saying "PL/PgSQL isn't perfect, so we shouldn't try and
> make it better".  I hear this argument a lot, and as long as people keep
> rejecting improvements for this reason they can keep saying it.  It's a
> self-fulfilling prophecy.

Agreed.  But adding language features, especially syntactical ones,
demands prudence; there is good reason to limit keywords like that.
What about:
pgsql.rows
pgsql.found
pgsql.sqlerrm
etc
as automatic variables (I think this was suggested upthread).
Conflicts with existing structures is of course an issue but I bet it
could be worked out.

I also kinda disagree on the brevity point, or at least would like to
add some color.  SQL is verbose in the sense of "let's make everything
an english language sentence" but incredibly terse relative to other
language implementations of the same task.   Embedded SQL tends to be
uniformly clumsy due to all of the extra handling of errrors,
parameterization, etc.  This is why we write plpgsql naturally.

merlin



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [HACKERS] pg_restore accepts -j -1
Next
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] PoC: Make it possible to disallow WHERE-less UPDATE and DELETE