Re: pgsql: Further code review for pg_lsn data type.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pgsql: Further code review for pg_lsn data type.
Дата
Msg-id 27636.1392909920@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pgsql: Further code review for pg_lsn data type.  (Andres Freund <andres@2ndquadrant.com>)
Ответы Re: pgsql: Further code review for pg_lsn data type.  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-committers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-02-20 09:59:51 -0500, Tom Lane wrote:
>> I think you're making a problem out of nothing.  We have considerably
>> more-real portability issues to worry about, like memory ordering.

> I don't think it's a huge problem, but it's pretty easy to avoid, so why
> not avoid it?

It's *not* that easy to avoid.  If we turn Datum into a struct we face a
very significant risk of performance problems: on many machines the rules
for passing structs to functions differ from those for passing scalars,
and not in a good way.

If there were one shred of evidence that there is a real problem here,
it might be worth looking into; but the fact is that you're wasting
our time by even bringing it up.  Consider for example that the printf
family of functions don't have any problem if you pass an int and ask for
it to be printed with %u, or vice versa.  That behavior involves exactly
the same type of casting you're complaining about, and in practice it
is perfectly portable.

            regards, tom lane


В списке pgsql-committers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: pgsql: Further code review for pg_lsn data type.
Следующее
От: Andres Freund
Дата:
Сообщение: Re: pgsql: Further code review for pg_lsn data type.