On Wed, Apr 25, 2018 at 04:39:42PM -0400, Tom Lane wrote:
> 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.
What do you rate the chances that someone created a foo_in when
there's already a built-in fooin? If it's low enough, we could add
all the foo_ins as aliases to fooins and then mandate that new ones be
called foo_in for future foos.
Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate