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

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Providing catalog view to pg_hba.conf file - Patch submission
Дата
Msg-id CAKFQuwa6DCrgHtBPmD6i1qES+LLXrGbvOsk+EugCQbmS2sgvhw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Providing catalog view to pg_hba.conf file - Patch submission  (Greg Stark <stark@mit.edu>)
Список pgsql-hackers
On Mon, Mar 16, 2015 at 11:11 AM, Greg Stark <stark@mit.edu> wrote:

On Mon, Mar 16, 2015 at 5:46 PM, David G. Johnston <david.g.johnston@gmail.com> wrote:
​Why not just leave the double-quoting requirements intact.  An unquoted <any> or <sameuser> (etc) would represent the special keyword while the quoted version would mean that the name is used literally.

For users that would be worse than not quoting. Then if they look up users they can't say WHERE username =ANY (users). They would have to do sumersaults like CASE WHEN username = 'all' then '"all"' =ANY (users) else username =ALL (users).

The whole point of having a view should be that you don't need to know the syntax rules for pg_hba.conf to interpret the data. If you do then you might as well just write a parser and read the file.



​Create a "pg_hba_user" type, and an implicit cast from text to that type, so when you say: "WHERE 'any' = ANY(...)" the system does the syntax conversion for you and the user doesn't have to, for the most part, be aware of the special rules for quoting names.  Otherwise I don't see how you can meet the requirement to accommodate "any" as a valid user identifier​
 
​without using two columns - one for keywords and one for users using the quoting rules of PostgreSQL pg_role instead of using the, more restrictive, rules of pg_hba.conf

​​
​In that case I would not leave the users column with an empty array when "any" is specified but would incorporate all known roles into the value; though maybe it is just noise during typical usage...it would likely be a long field that would be useful for querying but not necessarily for display.

​David J.​

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: assessing parallel-safety
Следующее
От: Tom Lane
Дата:
Сообщение: Future directions for inheritance-hierarchy statistics