Re: WIP: a way forward on bootstrap data

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: WIP: a way forward on bootstrap data
Дата
Msg-id 21556.1524688782@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: WIP: a way forward on bootstrap data  (Mark Dilger <hornschnorter@gmail.com>)
Ответы Re: WIP: a way forward on bootstrap data  (David Fetter <david@fetter.org>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..
Следующее
От: Mark Dilger
Дата:
Сообщение: Re: WIP: a way forward on bootstrap data