Re: Providing catalog view to pg_hba.conf file - Patch submission

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