Dave Page wrote:
The best I have come up with is functions similar to:
SELECT pg_set_hba_line(20, 'hostssl all all 192.168.1.1/32 md5');
SELECT pg_add_hba_line(19, '# Allow global access for Dave''s test
workstation');
SELECT pg_delete_hba_line(24);
However, there are a couple of things that concern me about doing it this way:
- It would make the client code much more complex as it would need to track
each change the user makes individually, before applying the end result.
- It doesn't really give us a cleaner, less hackish interface and just seems
like work for the sake of it.
I suppose we could just add functions like:
pg_write_hba_file('File contents'::text);
pg_read_hba_file() AS text;
Which would limit what the functions could be used for to their precisely
intended purpose, without compromising flexibility.
This is what bothers me about this whole exercise - it is addressed to
our particular storage method for this stuff. That's analogous to us
having to address tuples in pages directly, rather than using a higher
level abstraction like SQL. Ideally, any API would adapt to us changing
the storage methods completely (say by putting the info in tables)
without any change being necessary in the clients. That goes for the
config file as well as the hba file, although the hba file case is
harder because order is much more important.
Incidentally, I thought I had voiced some similar concerns some time ago
- I certainly know I have had them for a while - if I am late in
expressing them then I apologise. I would just hate to see us adopt a
bad solution now that would make moving to a good solution later much
harder.
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
