On Wed, Mar 4, 2015 at 9:41 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
> everyone seems to have quite different uses for it. Greg wants to join
> against other catalog tables, Jim wants to reassemble a valid and
> accurate pg_hba.conf, Josh wants to write an editing tool. Personally,
> I'd like to see something as close to the actual file as possible.
Well if you want to read the file as is you can do so using the file
reading functions which afaik were specifically intended for the
purpose of writing config editing tools.
Just to repeat, even if you're reassembling a valid and accurage
pg_hba.conf or writing an editing tool you can do that with what we
have today as long as there are no databases named "all", "sameuser",
or "samerole" and no roles named "all". That's something an editing
tool could check and provide a warning for to the user and refuse to
write a config file if it's the case and I doubt there are any such
users out there anyways.
Having five separate columns would work but I just think it's way more
complicated than necessary and burdens everyone who wants to use the
view less formally.
>
> If there were an obviously correct way to map the various special
> constructs to the available SQL data types, then fine. But if there
> isn't, then we shouldn't give a false overinterpretation. So I'd render
> everything that's disputed as a plain text field. (Not even an array of
> text.)
Joining against other catalog tables may be kind of exaggerated but if
I have data in an SQL view I certainly expect to be able to write
WHERE clauses to find the rows I want without having to do string
parsing. If it were a comma-delimited string I have to do something
like WHERE users LIKE '%,username,%' but then that's not good enough
since it may be the first or last and the username itself may contain
white-space or a comma etc etc.
I think knowing about the + prefix and the risk of tokens like "all"
and "sameuser" etc are pretty small compromises to make. But having to
know the quoting rules and write a tokenizer are too far.
--
greg