On 3/3/15 12:57 PM, Greg Stark wrote:
> On Tue, Mar 3, 2015 at 6:05 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>
>> What about a separate column that's just the text from pg_hba? Or is that what you're opposed to?
>
> I'm not sure what you mean by that. There's a rawline field we could
> put somewhere but it contains the entire line.
I mean have a field for each of user/databases that gives you valid
pg_hba.conf output. That would allow for cut & paste. But perhaps that's
just not a use case.
>> FWIW, I'd say that having the individual array elements be correct is more
>> important than what the result of array_out is. That way you could always do
>> array_to_string(..., ', ') and get valid pg_hba output.
>
> Well I don't think you can get that without making the view less
> useful for every other purpose.
>
> Like, I would want to be able to do WHERE "user" @> array[?] or WHERE
> database = array[?] or to join against a list of users or databases
> somewhere else.
I think we're screwed in that regard anyway, because of the special
constructs. You'd need different logic to handle things like +role and
sameuser. We might even end up painted in a corner where we can't change
it in the future because it'll break everyone's scripts.
> To do what you suggest would mean the tokens will need to be quoted
> based on pg_hba.conf syntax requirements. That would mean I would need
> to check each variable or join value against pg_hba.conf's quoting
> requirements to compare with it. It seems more practical to have that
> knowledge if you're actually going to generate a pg_hba.conf than to
> pass around these quoted strings all the time.
What about this:
- database_specials enum[] contains all occurrences of all, sameuser,
samerole and replication (or maybe it doesn't need to be an array)
- in_roles name[] is a list of all cases of +role_name, with the +
stripped off (I think the @ case is already handled before the SRF is
called??)
- role_specials enum[] handles all (enum[] for any future expansion)
Alternatively in_roles could just be combined with role_specials as long
as we preserve the +.
Any tokens that match the special conditions do not show up in
databases/users, and those fields become name[]. AFAIK that means the
quoting should be identical (at least looking at check_db() and
check_role()).
I can make these changes if you want.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
