On Wed, Apr 25, 2018 at 04:39:42PM -0400, Tom Lane wrote: > Mark Dilger <hornschnor...@gmail.com> writes: > >> On Apr 25, 2018, at 1:00 PM, Robert Haas <robertmh...@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
