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

From Pavel Stehule
Subject Re: [HACKERS] merging some features from plpgsql2 project
Date
Msg-id CAFj8pRAXxtMLUE3HKR7urxtxRbzZ0oY-wvWepXxLtVmOBoCEAQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] merging some features from plpgsql2 project  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers


2017-01-10 14:26 GMT+01:00 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>:
On 1/10/17 12:06 AM, Pavel Stehule wrote:
> A check how much rows was impacted by query is relative often task. So
> we can do this task more user friendly.
>
> Second motivation - ROW_COUNT is working for static and for dynamic SQL
> - it can be partial replace of FOUND variable.

What is stopping anyone from claiming that their favorite diagnostic
item is also a relatively often task and request it to become an
automatic variable?  Where does it stop?

There is only two possible fields - ROW_COUNT and RESULT_OID. Result Oid is not almost unused today. So stop is ROW_COUNT


It's not like PL/pgSQL is the king of brevity.  Creating inconsistent
and arbitrary warts to save a few characters does not appear appealing.

yes 

Regards

Pavel
 

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

pgsql-hackers by date:

Previous
From: Jesper Pedersen
Date:
Subject: Re: [HACKERS] Microvacuum support for Hash Index
Next
From: Jan de Visser
Date:
Subject: Re: [HACKERS] RustgreSQL