> On Nov 17, 2021, at 5:32 AM, Robert Haas <robertmh...@gmail.com> wrote:
>
>> I was aware of that, but figured not all GUCs have to be grantable. If it
>> doesn't fit in a NameData, you can't grant on it.
>
> Such restrictions are rather counterintuitive for users, and here it
> doesn't even buy anything. Using 'text' rather than 'name' as the data
> type isn't going to cost any meaningful amount of performance.
That sounds fine.
>> If we want to be more accommodating than that, we can store it as text, just
>> like pg_db_role_names does, but then we need more code complexity to look it
>> up and to verify that it is unique. (We wouldn't want multiple records for
>> the same <role,guc> pair.)
>
> If you're verifying that it's unique in any way other than using a
> unique index, I think you're doing it wrong.
No, I'm using a unique index. I was overthinking it, concerned about changing
from name_ops to text_ops and needing the toast table, but that's silly,
because I need one for the acl anyway.
> Also, maybe I'm confused here, but why isn't the schema:
>
> gucoid
> gucname
> gucacl
It is, both in v2 already posted, and in the v3, written but not yet posted, as
I haven't finished the pg_dump work, and also I'm waiting to see how this
discussion gets resolved before asking for a review of v3.
> IOW, I don't understand why this table has <role,guc> as the primary
> key rather than just guc.
I was responding to Tom's recommendation that I follow the pattern in
pg_db_role_setting, and speculating how that would work. I was not proposing
to do it that way.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
