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.
