Andres Freund writes:
> I don't really see a point in doing this renaming in the first
> place. It's not like the Temp suffix has become inaccurate. I'd perhaps
> not add it in the green field, but I don't see a need to change an
> existing function name. If anything it seems confusing because you
Andres Freund writes:
> On 2017-11-19 17:00:36 -0500, Tom Lane wrote:
>> No, but if you're concerned about it, we could maintain API compatibility
>> for extensions with something like
>> #define BufFileCreateTemp(interXact) BufFileCreate(interXact)
> I don't really see a point in doing this rena
On 2017-11-19 17:00:36 -0500, Tom Lane wrote:
> Thomas Munro writes:
> >> On 2017-11-17 11:23:54 -0500, Tom Lane wrote:
> >>> I wonder whether we should then rename BufFileCreateTemp to just
> >>> BufFileCreate, since it's no longer possible to have a BufFile that
> >>> isn't temp.
>
> > Here's a
Thomas Munro writes:
>> On 2017-11-17 11:23:54 -0500, Tom Lane wrote:
>>> I wonder whether we should then rename BufFileCreateTemp to just
>>> BufFileCreate, since it's no longer possible to have a BufFile that
>>> isn't temp.
> Here's a patch that does those things. I'm slightly surprised by th
On Sat, Nov 18, 2017 at 6:58 AM, Andres Freund wrote:
> On 2017-11-17 11:23:54 -0500, Tom Lane wrote:
>> OK, after looking through the history, the reason for isTemp = false
>> is indeed to allow BufFileCreate() to maintain its old semantics,
>> wherein you could attach a BufFile to an already-exi
Andres Freund writes:
> On 2017-11-17 11:23:54 -0500, Tom Lane wrote:
>> Or maybe we should revert 11e264517. It doesn't seem to be buying
>> much to make up for the loss of flexibility.
> There's a bunch of work adding new functionality to buffile.c
> pending. And having code paths that have be
Hi,
On 2017-11-17 11:23:54 -0500, Tom Lane wrote:
> OK, after looking through the history, the reason for isTemp = false
> is indeed to allow BufFileCreate() to maintain its old semantics,
> wherein you could attach a BufFile to an already-existing, possibly
> non-temp file. There have not been a
On Fri, Nov 17, 2017 at 8:23 AM, Tom Lane wrote:
> We should flat-out remove the function, since this change makes it
> impossible to resurrect with its old semantics. I wonder whether
> we should then rename BufFileCreateTemp to just BufFileCreate,
> since it's no longer possible to have a BufFi
I wrote:
> Andres Freund writes:
>> On 2017-11-16 21:58:14 -0500, Tom Lane wrote:
>>> [ squint... ] That used to have an actual purpose connected to
>>> transaction-abort cleanup, IIRC. It disturbs me that this seems
>>> to have been lost.
>> I've not found any such use, searching through buffi
Andres Freund writes:
> On 2017-11-16 21:58:14 -0500, Tom Lane wrote:
>> [ squint... ] That used to have an actual purpose connected to
>> transaction-abort cleanup, IIRC. It disturbs me that this seems
>> to have been lost.
> I've not found any such use, searching through buffile.c's history.
On 2017-11-16 21:58:14 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Remove BufFile's isTemp flag.
> > The isTemp flag controls whether buffile.c chops BufFile data up into
> > 1GB segments on disk. Since it was badly named and always true, get
> > rid of it.
>
> [ squint... ] That used to
Andres Freund writes:
> Remove BufFile's isTemp flag.
> The isTemp flag controls whether buffile.c chops BufFile data up into
> 1GB segments on disk. Since it was badly named and always true, get
> rid of it.
[ squint... ] That used to have an actual purpose connected to
transaction-abort clean
Remove BufFile's isTemp flag.
The isTemp flag controls whether buffile.c chops BufFile data up into
1GB segments on disk. Since it was badly named and always true, get
rid of it.
Author: Thomas Munro (based on suggestion by Peter Geoghegan)
Reviewed-By: Peter Geoghegan, Andres Freund
Discussion:
13 matches
Mail list logo
