Re: PL/pgSQL 2 - Mailing list pgsql-hackers

On 09/01/2014 11:19 PM, Joel Jacobson wrote:
> On Mon, Sep 1, 2014 at 5:16 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
>> On 09/01/2014 10:41 PM, Joel Jacobson wrote:
>>> This is exactly why we need a new language.
>>> All the clumsy stuff we cannot fix in plpgsql, can easily be fixed in
>>> plpgsql2, with the most beautiful syntax we can come up with.
>>>
>>> I guess it's a question if we want to support things like this. If we
>>> want to, then we also want a new language.
>>
>> Given how much bike shedding occurs around trivial features, can you
>> imagine how long that'd take?
> 
> I wasn't aware of the expression "bike shedding" so I had to look it up.
> It apparently means "spend the majority of its time on relatively
> unimportant but easy-to-grasp issues".
> If you feel the development of plpgsql falls into this category, that
> most time is spent on the smaller unimportant things, isn't that a
> clear sign we need plpgsql2, for there to be any hope of progress on
> the important things?

Er, no.

My point is that weeks can be spent just arguing about whether you
should have a variable-delimiter ($variable) or not, how syntax should
look, etc. Imagine how long it'd take to get a new language syntax
agreed upon?

You jumped in to say that you thought that:
 EXECUTE format("SELECT %I FROM %I WHERE $1", col, tbl) USING val;

was "is exactly why we need a new language" and that "All the clumsy
stuff we cannot fix in plpgsql, can easily be fixed in plpgsql2, with
the most beautiful syntax we can come up with." But you haven't said HOW
you propose to fix this one case.

Show me. How do you want this to look? The user requirement is "Execute
a SELECT against a table whose name is provided at runtime, selecting a
column or set of columns whose names are provided at runtime, with
literals substituted as placement parameters."

The above is ugly. Fine, not arguing. Show me what you want instead.


You're happy to say how much you dislike PL/PgSQL, but I haven't seen a
concrete proposal on how you want something new to look. That would be a
useful and constructive start, as we could then examine, point-by-point,
how/if those needs can be met in PL/PgSQL. If they can't then you'd have
a more convincing argument for a new version than "PL/PgSQL sucks".

-- Craig Ringer                   http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services