Re: BufFileRead() error signalling - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: BufFileRead() error signalling
Date
Msg-id 20200527225804.GA16389@alvherre.pgsql
Whole thread Raw
In response to Re: BufFileRead() error signalling  (Thomas Munro <thomas.munro@gmail.com>)
List 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



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: BufFileRead() error signalling
Next
From: Mark Dilger
Date:
Subject: Re: New 'pg' consolidated metacommand patch