On 3/3/15 12:57 PM, Greg Stark wrote:
On Tue, Mar 3, 2015 at 6:05 PM, Jim Nasby <jim.na...@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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to