From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | t-ishii(at)sra(dot)co(dot)jp, hackers(at)postgreSQL(dot)org |
Subject: | Re: [HACKERS] acl problem in NetBSD/m68k |
Date: | 1999-06-29 14:05:08 |
Message-ID: | 19846.930665108@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
>> There are two ways we could attack this: (1) put a "pad" field into
>> struct AclItem (prolly two uint8s) to try to ensure that compilers
>> would think it is 8 bytes long, or (2) make the size field for aclitem
>> in pg_type.h read "sizeof(AclItem)". I think the latter is a better
>> long-term solution, because it eliminates having to try to guess
>> what a compiler will do with a struct declaration.
> Currently, initdb runs through pg_type.h using sed/awk, so it can't
> see any of the sizeof() defines.
Hmm, that does put a bit of a crimp in the idea :-(
> I guess we don't have any other 'struct' data types that need
> to know the size of the struct on a give OS.
Right now I think all the other ones are either single-type structs (eg
point is two float8s, so no padding) or varlena. But this is something
that will come up again, I foresee...
> Maybe padding with an Assert() to make sure it stays at the fixed size
> we specify is a good solution.
I agree, that's probably an OK patch for now. When we have more than
one such type it'll probably be time to bite the bullet and implement
a clean solution.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 1999-06-29 14:31:38 | Re: [HACKERS] regression bigtest needs very long time |
Previous Message | Bruce Momjian | 1999-06-29 13:33:31 | Re: [HACKERS] regression bigtest needs very long time |