Re: merging some features from plpgsql2 project

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

2017-01-11 15:37 GMT+01:00 Merlin Moncure <mmoncure(at)gmail(dot)com>:

> On Tue, Jan 10, 2017 at 7:44 AM, Marko Tiikkaja <marko(at)joh(dot)to> wrote:
> > On Tue, Jan 10, 2017 at 2:26 PM, Peter Eisentraut
> > <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.
>
> 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.
>

Any implicit namespace can be problem. But we can continue in default
unlabeled namespace for auto variables with possibility to specify this
namespace explicitly.

Regards

Pavel

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2017-01-11 16:48:25 Re: pg_restore accepts -j -1
Previous Message Bruce Momjian 2017-01-11 16:27:11 Re: WARM and indirect indexes