Re: pgsql: Further code review for pg_lsn data type. - Mailing list pgsql-committers

From Tom Lane
Subject Re: pgsql: Further code review for pg_lsn data type.
Date
Msg-id 27636.1392909920@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgsql: Further code review for pg_lsn data type.  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: pgsql: Further code review for pg_lsn data type.  (Andres Freund <andres@2ndquadrant.com>)
List 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 by date:

Previous
From: Andres Freund
Date:
Subject: Re: pgsql: Further code review for pg_lsn data type.
Next
From: Andres Freund
Date:
Subject: Re: pgsql: Further code review for pg_lsn data type.