Thread: OID unsigned long long

OID unsigned long long

From
mlw
Date:
I am thinking about embarking on changing the typedef of OID to unsigned long
long.

My plan is to make it conditional at configure time, i.e.

#ifdef OID_ULONGLONG
typedef unsigned long long Oid;
#define OID_MAX  ULLONG_MAX
#else
typedef unsigned int Oid;
#define OID_MAX  UINT_MAX
#endif

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?


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


Re: OID unsigned long long

From
Larry Rosenman
Date:
* mlw <markw@mohawksoft.com> [010813 21:06]:
> I am thinking about embarking on changing the typedef of OID to unsigned long
> long.
> 
> My plan is to make it conditional at configure time, i.e.
> 
> #ifdef OID_ULONGLONG
> typedef unsigned long long Oid;
> #define OID_MAX  ULLONG_MAX
> #else
> typedef unsigned int Oid;
> #define OID_MAX  UINT_MAX
> #endif
> 
> 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?
> 
The wire protocol.......

LER

> 
> -- 
> 5-4-3-2-1 Thunderbirds are GO!
> ------------------------
> http://www.mohawksoft.com
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
> 

-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749


Re: OID unsigned long long

From
Tom Lane
Date:
mlw <markw@mohawksoft.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.

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.  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


Re: OID unsigned long long

From
mlw
Date:
Tom Lane wrote:
> 
> mlw <markw@mohawksoft.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@postgresql.org

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


Re: OID unsigned long long

From
Peter Eisentraut
Date:
mlw writes:

> I am thinking about embarking on changing the typedef of OID to unsigned long
> long.

> 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?

You can start with my patch at

http://www.ca.postgresql.org/~petere/oid8.html

See the comments on that page and the other responses.  It ain't pretty.

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter



Re: OID unsigned long long

From
David Ford
Date:
Tom Lane wrote:

>[...]
>
>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.  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.
>

You can ask gcc to typecheck format strings for printf type functions 
with something like the following:

extern int
my_printf (void *my_object, const char *my_format, ...)     __attribute__ ((format (printf, 2, 3)));


Ref: http://www.delorie.com/gnu/docs/gcc/gcc_77.html

David