| From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Marko Tiikkaja <marko(at)joh(dot)to>, 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-10 13:41:39 |
| Message-ID: | CAFj8pRAXxtMLUE3HKR7urxtxRbzZ0oY-wvWepXxLtVmOBoCEAQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
2017-01-10 14:26 GMT+01:00 Peter Eisentraut <
peter(dot)eisentraut(at)2ndquadrant(dot)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
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jan de Visser | 2017-01-10 13:42:29 | Re: RustgreSQL |
| Previous Message | Jesper Pedersen | 2017-01-10 13:40:08 | Re: Microvacuum support for Hash Index |