Обсуждение: OID unsigned long long
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
* 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
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
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
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
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