Regrading TODO item alerting pg_hba.conf from SQL

Folks,

I would like to start a discussion regarding the TODO item "%Allow
pg_hba.conf settings to be controlled via SQL"

In the past threads we have been talking about some of the options of
how this could be done. I would like to discuss the following items to
get more clarity.

1. What do we think about removing the pg_hba.conf functionality keeping
the connection information in a table. This would mean no more
pg_hba.conf and when something goes wrong with the table, pg has to be
started in standalone mode to correct the errors. 

I understand some would disagree with the option above regarding the
security. Reading the past threads I have to reconsider my thoughts.
I do not thing it would make it less secure to implement the option
above. But of course this is very much debatable.

1.1 For the backward compatibility reasons we could auto import the
exiting pg_hba.conf file once and then discard/rename/delete it.

2. What do we think about the SQL command to be. Would it be like the
following or another syntax. 

GRANT CONNECTION [LOCAL | HOST | HOSTSSL | HOSTNOSSL ] ON [ ALL | mydatabase1 ]TO [ ALL | user1,user2,user3 ]FROM
127.0.0.1/32METHOD[ TRUST | REJECT | MD5 ...... ]
 

3. Could someone clarify the design decisions regarding pg_hba.conf
file? Why was it done the why it is today? (Tom? Bruce?)


As suggested in the DEV_FAQ I would like to gather as much information
as possible before doing anything.

Regards,
Gevik.