From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mark Dilger <hornschnorter(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, John Naylor <jcnaylor(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: a way forward on bootstrap data |
Date: | 2018-04-25 20:39:42 |
Message-ID: | 21556.1524688782@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Mark Dilger <hornschnorter(at)gmail(dot)com> writes:
>> On Apr 25, 2018, at 1:00 PM, Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Dilger | 2018-04-25 20:41:24 | Re: WIP: a way forward on bootstrap data |
Previous Message | Andres Freund | 2018-04-25 20:33:33 | Re: [HACKERS] lseek/read/write overhead becomes visible at scale .. |