Re: [PATCH] Implement motd for PostgreSQL - Mailing list pgsql-hackers

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.