Hello Joel,
My 0.02€:
If such a feature gets considered, I'm not sure I'd like to actually edit
pg configuration file to change the message.
For the ALTER SYSTEM case, the value would be written to postgresql.auto.conf,
and that file we shouldn't edit manually anyway, right?
Sure. I meant change the configuration in any way, through manual editing,
alter system, whatever.
The actual source looks pretty straightforward. I'm wondering whether pg
style would suggest to write motd != NULL instead of just motd.
That's what I had originally, but when reviewing my code verifying code style,
I noticed the other case it more common:
If other cases are indeed pointers. For pgbench, all direct "if (xxx &&"
cases are simple booleans or integers, pointers seem to have "!= NULL".
While looking quickly at the grep output, ISTM that most obvious pointers
have "!= NULL" and other cases often look like booleans:
catalog/pg_operator.c: if (isDelete && t->oprcom == baseId)
catalog/toasting.c: if (check && lockmode != AccessExclusiveLock)
commands/async.c: if (amRegisteredListener && listenChannels == NIL)
commands/explain.c: if (es->analyze && es->timing)
…
I'm sure there are exceptions, but ISTM that the local style is "!= NULL".
I'm wondering whether it should be possible to designate (1) a file the
content of which would be shown, or (2) a command, the output of which
would be shown [ok, there might be security implications on this one].
Can't we just do that via plpgsql and EXECUTE somehow?
Hmmm.
Should we want to execute forcibly some PL/pgSQL on any new connection?
Not sure this is really desirable. I was thinking of something more
trivial, like the "motd" directeve could designate a file instead of the
message itself.
There could be a hook system to execute some user code on new connections
and other events. It could be a new kind of event trigger, eg with
connection_start, connection_end… That could be nice for other purposes,
i.e. auditing. Now, event triggers are not global, they work inside a
database, which would suggest that if extended a new connection event
would be fired per database connection, not just once per connection. Not
sure it would be a bad thing.
--
Fabien.
