Re: OID unsigned long long

From: mlw <markw(at)mohawksoft(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: OID unsigned long long
Date: 2001-08-14 11:39:57
Message-ID: 3B790E0D.C03177A7@mohawksoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
>
> mlw <markw(at)mohawksoft(dot)com> writes:
> > Aside from adding %llu to all the %u everywhere an OID is used in a
> > printf, and any other warnings, are there any other things I should be
> > specially concerned about?
>
> FE/BE protocol, a/k/a client/server interoperability. Flagging a
> database so that a backend with the wrong OID size won't try to run in
> it. Alignment --- on machines where long long has to be 8-byte aligned,
> TOAST references as presently constituted will crash, because varlena
> datatypes in general are only 4-byte aligned. There are more, but that
> will do for starters.

I will have to look at that, thanks.

>
> BTW, I think #ifdef would be a totally unworkable way to attack the
> format-string problem. The code clutter of #ifdef'ing everyplace that
> presently uses %u would be a nightmare; the impact on
> internationalization files would be worse. And don't forget that %llu
> would be the right thing on only some machines; others like %qu, and
> DEC Alphas think %lu is just fine.

What do you think of making two entries in the various printf strings, and
using macros to split up an OID, as:

printf("OID: %u:%u", HIGHOID(od) LOWOID(oid))

That may satisfy your concern for #ifdef's everywhere, and it could mean I
could submit my patches back without breaking any code, so PostgreSQL could be
closer to a 64 bit OID.

> The only workable answer I can see
> is for the individual messages to use some special code, maybe "%O" for
> Oid. The problem is then (a) translating this to the right
> platform-dependent thing, and (b) persuading gcc to somehow type-check
> the elog calls anyway.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org

--
5-4-3-2-1 Thunderbirds are GO!
------------------------
http://www.mohawksoft.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 2001-08-14 12:40:21 Re: Surviving transaction-ID wraparound, take 2
Previous Message Tatsuo Ishii 2001-08-14 05:01:30 Re: Vague idea for allowing per-column locale