Re: merging some features from plpgsql2 project

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Marko Tiikkaja <marko(at)joh(dot)to>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Joel Jacobson <joel(at)trustly(dot)com>
Subject: Re: merging some features from plpgsql2 project
Date: 2017-01-11 17:11:30
Message-ID: fe377e4b-c3c4-4d47-38ba-f11ed45eac36@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1/10/17 8:44 AM, Marko Tiikkaja wrote:
> On Tue, Jan 10, 2017 at 2:26 PM, Peter Eisentraut
> <peter(dot)eisentraut(at)2ndquadrant(dot)com
> <mailto:peter(dot)eisentraut(at)2ndquadrant(dot)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.

I'm not making that argument. But if the plan here is that PL/pgSQL is
too verbose, let's make it less verbose, then maybe, but let's see a
more complete plan for that.

The current syntax was chosen because it is SQL-compatible. Adding
redundant syntax to save a few characters without any new functionality
(performance, resource usage, safety, etc.) is a weak argument in the
overall scheme of things.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-01-11 17:25:27 Re: Proposal for changes to recovery.conf API
Previous Message Peter Eisentraut 2017-01-11 17:02:46 Re: [HACKERS] Questionable tag usage