On Fri, Oct 25, 2024 at 10:52:38AM +0200, Thomas Landauer via Postfix-users wrote:
> > > The expansion parameters `%s`, `%u` and `%d` are not working as > > > documented: > > > > You're mistaken. The behaviour is exactly as documented. > > Sorry, but where is this documented at > https://www.postfix.org/pgsql_table.5.html ? I see explanations for each > expansion parameter, but I don't see any note that if I pass `%s`, I get in > fact queries with `%s`, `%u` and `%d`. > > Is it possible to suppress these additional queries? I.e. just query for > `%s`, and if nothing is found, then fail? You did not read my original response carefully. At the Postgresql table layer there are no additional queries using '%d' or '%u', etc. Rather, Postfix address rewriting makes multiple queries against whatever tables are configured, using various fragments of the input address as documented for virtual(5), aliases(5), canonical(5), etc. The same multiple queries happen with LDAP, hash, cdb, lmdb, ... and have nothing to do with Postgres. > * You should add a password. I think you mean that the documentation should include a password in the example URI. Perhaps so, though in some cases (unix-domain sockets) none is needed. > * You should mention that the entire string needs to be urlencoded (I guess) That's false. Individual components that happen to contain a "/" or ":", ... may need to be encoded, this is documented in Postgres docs, and it is the job of Postfix to document Postgres connection string syntax. We just could perhaps reference some version of the Postgres docs, and mention that the connection string needs to be self-contained, covering any non-default databasename, username and password, as well as various connection-related options as covered by the Postgres docs. > * You should use 127.0.0.1 as address, since this is (probably) what most > people need. That will work poorly with SSL. The reason to have a Postgres database, as opposed to something simple like "cdb" tables, is to share data across multiple hosts, so I'm sceptical that "127.0.0.1" is the norm for using Postfix with a Postgres table backend. If you just have a single machine, a Postgres backend is rather overkill. > * You should explain how options are working. Based on your other comments, > I guess you should write something like: > > > Connection options from > https://www.postgresql.org/docs/current/app-psql.html can be appended to the > connection string like that: > .../databasename?sslmode=require&foo=bar > > The following Postfix-options need to be given as separate key and cannot > be appended to the connection string: > idle_interval > retry_interval > ... This belongs in Postgres docs, Postfix can/should not attempt to provide comprehensive coverage of this. > And this sentence: > > > Historically, the database client was hard coded to use LATIN1 in an > > attempt to disable multibyte character support. > > should be change to something like: > > > Through Postfix 3.7, the database client was hard coded to use LATIN1... The Postfix documentation consistently covers that first release in which various features are introduced, it is not too difficult to conclude that the feature is missing in earlier releases. > Cause the existing "This feature is available in Postfix 3.8 and later." > only tells people that they cannot change it in 3.7; while in fact the other > sentence about UTF8 being the default is wrong for 3.7. The default setting of the "encoding" parameter is UTF8, the parameter (new 3.8). Historically, before the new parameter, this was hardcoded to LATIN1. You don't need to save face by working hard to misread this. > > We could add a ton of code to parse a postgresql:// URI and find > > out if it specifies a database name, but that does not seem right. > > Oh, you don't look into the connection string, but just pass it to psql and > see what happens? (Didn't know that...) > Then I would suggest to just make `dbname` not required anymore, and that's > it. Cause when user & password are optional, and dbname is required, that's > a little strange, isn't it? Postfix only checks the URI scheme, it is correctly deliberately ignorant of the URI content. Parsing it is the job of the Postgresql library (libpq). That said, I think we should match on: postgresql:// postgres:// **with** the "//" suffixes after the ":", otherwise legacy syntax with hosts named "postgres" or "postgresql" to some ":port" may be misread as URIs, but they are not, absent "//". -- Viktor. _______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
