| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BufFileRead() error signalling |
| Date: | 2020-05-27 22:58:04 |
| Message-ID: | 20200527225804.GA16389@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2020-May-28, Thomas Munro wrote:
> My indecision on the back-patching question has been resolved by your
> crash report and a search on codesearch.debian.org.
Great news!
> BufFileRead() and BufFileWrite() aren't referenced by any of the
> extensions they package, so by that standard it's OK to change this
> stuff in back branches.
This makes me a bit uncomfortable. For example,
https://inst.eecs.berkeley.edu/~cs186/fa03/hwk5/assign5.html (admittedly
a very old class) encourages students to use this API to create an
aggregate. It might not be the smartest thing in the world, but I'd
prefer not to break such things if they exist proprietarily. Can we
keep the API unchanged in stable branches and just ereport the errors?
> I'll post a rebased a patch with Robert and Ibrar's changes
> for last reviews later today.
... walks away wondering about BufFileSeekBlock's API ...
(BufFileSeek seems harder to change, due to tuplestore.c)
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Mark Dilger | 2020-05-27 23:00:03 | Re: New 'pg' consolidated metacommand patch |
| Previous Message | Thomas Munro | 2020-05-27 21:58:43 | Re: BufFileRead() error signalling |