Re: [HACKERS] acl problem in NetBSD/m68k
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] acl problem in NetBSD/m68k |
Дата | |
Msg-id | 19846.930665108@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] acl problem in NetBSD/m68k (Bruce Momjian <maillist@candle.pha.pa.us>) |
Список | pgsql-hackers |
Bruce Momjian <maillist@candle.pha.pa.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
В списке pgsql-hackers по дате отправления: