Re: [HACKERS] acl problem in NetBSD/m68k - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] acl problem in NetBSD/m68k
Date
Msg-id 28866.931442198@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] acl problem in NetBSD/m68k  (Bruce Momjian <maillist@candle.pha.pa.us>)
Responses Re: [HACKERS] acl problem in NetBSD/m68k
List pgsql-hackers
Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Did we ever fix this?

We agreed what to do: add padding field(s) to struct AclItem and
add an Assert() somewhere that would check that sizeof(AclItem) is 8,
while leaving the bulk of the code using sizeof(AclItem) rather than
a #define constant.

But it doesn't look like it got done yet.
        regards, tom lane

>>>>> grant/revoke does not work in NetBSD/m68k. This is due to the wrong
>>>>> assumption that sizeof(AclItem) is equal to 8 in all platforms. I am
>>>>> going to fix this by replacing all occurrence of sizeof(AclItem) to
>>>>> ACLITEM_SIZE (newly defined as 8 in catalog/pg_type.h). See included
>>>>> patches. If there's no objection, I will commit them. Comments?
>>>> 
>>>> I do not like this patch at *all*.  Why is sizeof(AclItem) not the
>>>> correct thing to use?
>> 
>> In NetBSD/m68k sizeof(AclItem) = 6, not 8.
>> 
>>>> Replacing it with a hardwired "8" seems like
>>>> a step backwards --- not to mention a direct contradiction of what
>>>> you claim the patch is doing.
>> 
>> It's already hard wired in pg_type.h, isn't it.
>> 
>>>> Perhaps the real problem is that the AclItem struct definition needs
>>>> modification?  Or maybe we need a way to put a machine-dependent size
>>>> into the pg_type entry for type aclitem?  The latter seems like a
>>>> good thing to be able to do on general principles.
>> 
>> Glad to hear you have better idea. Anyway, NetBSD/m68k users need some 
>> way to fix the problem now, since the problem seems very serious.
>> --
>> Tatsuo Ishii


pgsql-hackers by date:

Previous
From: wieck@debis.com (Jan Wieck)
Date:
Subject: Re: [HACKERS] Delaying insertion of default values
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] PATCH for pgconnection.h