Re: WIP: a way forward on bootstrap data - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WIP: a way forward on bootstrap data
Date
Msg-id 21556.1524688782@sss.pgh.pa.us
Whole thread Raw
In response to Re: WIP: a way forward on bootstrap data  (Mark Dilger <hornschnorter@gmail.com>)
Responses Re: WIP: a way forward on bootstrap data
List pgsql-hackers
Mark Dilger <hornschnorter@gmail.com> writes:
>> On Apr 25, 2018, at 1:00 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> -1 for trying to automate this.  It varies between fooin and foo_in,
>> and it'll be annoying to have to remember which one happens
>> automatically and which one needs an override.

> That may be a good argument.  I was on the fence about it, because I
> like the idea that the project might do some cleanup and standardize
> the names of all in/out/send/recv functions so that no overrides would
> be required.  (Likewise, I'd like the eq,ne,lt,le,gt,ge functions to
> be named in a standard way.)

> Would that be an API break and hence a non-starter?

Yeah, I'm afraid so.  I'm pretty sure I recall cases where people
invoked I/O functions by name, and I definitely recall cases where
operator-implementation functions were invoked by name.  Those might
not be very bright things to do, but people do 'em.

We'd also be risking creating problems for individual apps by conflicting
with user-defined functions that we didn't use to conflict with.  We take
that chance every time we add functionality, of course, but usually we can
soothe complaints by pointing out that they got some new functionality in
return.  I don't think "we made I/O function names more uniform" is going
to be a very satisfactory excuse for breakage.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..
Next
From: Mark Dilger
Date:
Subject: Re: WIP: a way forward on bootstrap data