Обсуждение: Proposal: wildcards in pg_service.conf

I'd like to extend the libpq service file by allowing
wildcards, e.g. like this:

[%]
host=dbhost.mycompany.com
dbname=%

Such an entry would match all service parameters,
and all ocurrences of the wildcard right of a = would
be replaced with the service parameter.

That implies that a [%] entry is only useful as last entry
in pg_service.conf.

I'd like to keep it simple and only accept standalone
wildcards (not things like 'prefix%suffix'), but that's
debatable (at the cost of more work).

As a special case, I would want to allow wildcards in LDAP URLs
like this:

[%]
ldap://ldap.mycompany.com/cn=%,cn=databases?connectstring?one?objectclass=*

This also explains my preference of '%' over '*' as a
wildcard to avoid problems with * in LDAP filter expressions.

The added value is that you don't need one line per database
in the configuration file.

The two examples above illustrate two cases where I think that
such a setup could be useful:
a) You have "most of" your databases in one cluster.
b) You use LDAP to store your connection parameters centrally.

What do you think?

Yours,
Laurenz Albe

"Albe Laurenz" <laurenz.albe@wien.gv.at> writes:
> I'd like to extend the libpq service file by allowing
> wildcards, e.g. like this:

> [%]
> host=dbhost.mycompany.com
> dbname=%

> Such an entry would match all service parameters,
> and all ocurrences of the wildcard right of a = would
> be replaced with the service parameter.

This seems poorly thought out.  How could you have any other service
entries besides this one?  What is the point of doing it like this
and not simply overriding the service's database selection?

The special case for LDAP makes it even more obvious that this is
a kluge.
        regards, tom lane

Tom Lane wrote:
>> I'd like to extend the libpq service file by allowing
>> wildcards, e.g. like this:
>
>> [%]
>> host=dbhost.mycompany.com
>> dbname=%
>
>> Such an entry would match all service parameters,
>> and all ocurrences of the wildcard right of a = would
>> be replaced with the service parameter.
>
> This seems poorly thought out.  How could you have any other service
> entries besides this one?  What is the point of doing it like this
> and not simply overriding the service's database selection?

You could have other service entries if you put them _before_
the wildcard entry.

Your second critizism is valid - you could handle this case without
wildcards.

> The special case for LDAP makes it even more obvious that this is
> a kluge.

The LDAP case is the main motivation why I would like to have
wildcards, so that all our databases could be handled with one
entry in the service file. Currently we have to add an entry to the
file for every new database we want to access.

Do you think that the idea of wildcards for the service file
is a bad one in general?

Or could there be a more generally useful realization of that
concept?

Yours,
Laurenz Albe

On Thu, Feb 28, 2008 at 11:27 AM, Albe Laurenz <laurenz.albe@wien.gv.at> wrote:
>  The LDAP case is the main motivation why I would like to have
>  wildcards, so that all our databases could be handled with one
>  entry in the service file. Currently we have to add an entry to the
>  file for every new database we want to access.

I am very much +1 for it.  I think it would be very useful.

>  Do you think that the idea of wildcards for the service file
>  is a bad one in general?
>
>  Or could there be a more generally useful realization of that
>  concept?

The use of [%] in pg_service.conf is well... ugly. :)  (At the same time
I would have come up with exactly the same idea for the syntax...)

As for LDAP string expansion I think it would be convenient to
provide a subset of log_line_prefix %x expansions, like:

%u       User name
%d    Database name
%r    Remote host name or IP address, and remote port
%h    Remote host name or IP address
%%    Literal %

...I am not sure if %r or %h is a good idea.  Thoughts?

As for the syntax of configuration file, using [%] implies that things
like [proj%db] would also be valid, which would be harder to implement.

Perhaps empty bracers [] would be better?  Ugly aswell, but would not
suggest you can use [pr%db%test] and expect it to work.  And could
be made as 'last match' regardless of the in-file order.
  Regards,    Dawid