Thread: [PATCH] Implement motd for PostgreSQL

On Fri, Apr  2, 2021 at 10:46:16PM +0200, Joel Jacobson wrote:
> Dear fellow hackers,
> 
> This patch is one day late, my apologies for missing the deadline this year.

Uh, the deadline for the last commitfest was March 1, 2021, not April
1.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  If only the physical world exists, free will is an illusion.

On 04/02/21 16:46, Joel Jacobson wrote:

>    ____  ______  ___
>   /    )/      /
> (     / __    _    )
>       (/ o)  ( o)   )
>    _  (_  )    )  /
>        /_/    )_/
>       /  //|  |\
>           v |  | v
>             __/


Slonik's backslashes are falling off. Eww.

Regards,
-Chap

On Fri, Apr 02, 2021 at 10:46:16PM +0200, Joel Jacobson wrote:
> Ascii elephant in example by Michael Paquier [1], with ANSI colors added by me.
>
> [1] https://www.postgresql.org/message-id/CAB7nPqRaacwcaANOYY3Hxd3T0No5RdZXyqM5HB6fta%2BCoDLOEg%40mail.gmail.com

The credit here goes to Charles Clavadetscher, not me.
--
Michael

On Fri, Apr  2, 2021 at 10:46:16PM +0200, Joel Jacobson wrote:

> Dear fellow hackers,

> 

> This patch is one day late, my apologies for missing the deadline this year.

Uh, the deadline for the last commitfest was March 1, 2021, not April

1.

On Fri, Apr 02, 2021 at 10:46:16PM +0200, Joel Jacobson wrote:

> Ascii elephant in example by Michael Paquier [1], with ANSI colors added by me.

> 

> [1] https://www.postgresql.org/message-id/CAB7nPqRaacwcaANOYY3Hxd3T0No5RdZXyqM5HB6fta%2BCoDLOEg%40mail.gmail.com

The credit here goes to Charles Clavadetscher, not me.

--

Michael

Slonik's backslashes are falling off. Eww.

Regards,

-Chap

Hi Joel

On Fri, Apr 2, 2021 at 11:47 PM Joel Jacobson <joel@compiler.org> wrote:

PostgreSQL has since long been suffering from the lack of a proper UNIX style motd (message of the day).

First of all, thanks for your work on this!  I think this is an important feature to have, but I would love to see a way to have a set of strings from which you choose a random one to display.  That way you could brighten your day with random positive messages.

-marko

Hi

On 2021-04-03 07:16, Joel Jacobson wrote:
> On Sat, Apr 3, 2021, at 04:47, Michael Paquier wrote:
> 
>> On Fri, Apr 02, 2021 at 10:46:16PM +0200, Joel Jacobson wrote:
>> 
>>> Ascii elephant in example by Michael Paquier [1], with ANSI colors
>> added by me.
>> 
>>> 
>> 
>>> [1]
>> 
> https://www.postgresql.org/message-id/CAB7nPqRaacwcaANOYY3Hxd3T0No5RdZXyqM5HB6fta%2BCoDLOEg%40mail.gmail.com
>> 
>> The credit here goes to Charles Clavadetscher, not me.
>> 
>> --
>> 
>> Michael
> 
> Right! Sorry about that. The initial ">" in front of the ascii art
> confused me, didn't understand it was part of the reply, since all
> text around it was your.
> 
> Many thanks Charles for the beautiful ascii art!
> 
> /Joel

You are welcome. There were some discussions until it came to the final 
form (that you can see below).
You may also want to have a look at this:

https://www.swisspug.org/wiki/index.php/Promotion

It includes a DB-Function that can be used to create the ASCII image 
with texts.

Regards
Charles

-- 
Charles Clavadetscher
Swiss PostgreSQL Users Group
Treasurer
Spitzackerstrasse 9
CH - 8057 Zürich

http://www.swisspug.org

+---------------------------+
|     ____  ______  ___     |
|    /    )/      \/   \    |
|   (     / __    _\    )   |
|    \    (/ o)  ( o)   )   |
|     \_  (_  )   \ ) _/    |
|       \  /\_/    \)/      |
|        \/ <//|  |\\>      |
|             _|  |         |
|             \|_/          |
|                           |
|     Swiss PostgreSQL      |
|       Users Group         |
|                           |
+---------------------------+

Hello Joel,

> This patch is one day late, my apologies for missing the deadline this year.
>
> PostgreSQL has since long been suffering from the lack of a proper UNIX style motd (message of the day).

My 0.02€: apart from the Fool's day joke dimension, I'd admit that I would 
not mind actually having such a fun feature in pg, possibly disabled by 
default.

-- 
Fabien.

Hello Joel,

> This patch is one day late, my apologies for missing the deadline this year.

>

> PostgreSQL has since long been suffering from the lack of a proper UNIX style motd (message of the day).

My 0.02€: apart from the Fool's day joke dimension, I'd admit that I would 

not mind actually having such a fun feature in pg, possibly disabled by 

default.

On 04/03/21 01:20, Joel Jacobson wrote:
> I've deployed the fix to production:
> 
> $ psql -U brad -h pit.org motd
> 
> NOTICE:
>    ____  ______  ___
>   /    )/      \/   \
> (     / __    _\    )
>   \    (/ o)  ( o)   )
>    \_  (_  )   \ )  /
>      \  /\_/    \)_/
>       \/  //|  |\\
>           v |  | v
>             \__/

Now there's some kind of Max Headroom thing going on with the second row,
and this time I'm not sure how to explain it. (I knew the backslashes were
because they weren't doubled.)

I have done 'view source' in my mail client to make sure it's not just
some display artifact on my end. Something has eaten a space before that
left paren. What would do that?

Regards,
-Chap

> Perhaps the configuration-file parser has been fixed since to support 
> embedded newlines? If so, then maybe it would actually be an idea to 
> support newlines by escaping them?

Dunno.

If such a feature gets considered, I'm not sure I'd like to actually edit 
pg configuration file to change the message.

The actual source looks pretty straightforward. I'm wondering whether pg 
style would suggest to write motd != NULL instead of just motd.

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].

-- 
Fabien.

Now there's some kind of Max Headroom thing going on with the second row,

and this time I'm not sure how to explain it. (I knew the backslashes were

because they weren't doubled.)

I have done 'view source' in my mail client to make sure it's not just

some display artifact on my end. Something has eaten a space before that

left paren. What would do that?

On 04/03/21 14:24, Joel Jacobson wrote:
> Thanks for noticing.
> I've updated the ascii art now using the version from swisspug.org,
> does it look correct now to you?
> 
> $ psql -U brad -h pit.org motd
> 
> NOTICE:
>   ____  ______  ___
> /    )/      \/   \
> (     / __    _\    )
> \    (/ o)  ( o)   )
>   \_  (_  )   \ ) _/
>     \  /\_/    \)/
>      \/ <//|  |\\>
>           _|  |
>           \|_/

In the email as I received it (including in view-source, so it is
not a display artifact), rows 2 and 4 are now missing an initial space.

I've pulled up the version from the list archive also[1], and see the
same issue there.

I'm not /only/ trying to be funny here ... I'm wondering if there could
be something relevant to be learned from finding out where the initial
space is being dropped, and why.

Regards,
-Chap


[1]
https://www.postgresql.org/message-id/b8855527-88f5-4613-a258-8523cbded8be%40www.fastmail.com

On 2021-Apr-03, Joel Jacobson wrote:

> I'm actually using it myself in production for something, to display
> instructions to users when they login.

Yeah, such as

"If your CREATE sentences don't work, please run
CREATE SCHEMA AUTHORIZATION CURRENT_USER"

for systems where the PUBLIC schema has been dropped.

-- 
Álvaro Herrera       Valdivia, Chile
<Schwern> It does it in a really, really complicated way
<crab> why does it need to be complicated?
<Schwern> Because it's MakeMaker.

> Perhaps the configuration-file parser has been fixed since to support 

> embedded newlines? If so, then maybe it would actually be an idea to 

> support newlines by escaping them?

Dunno.

If such a feature gets considered, I'm not sure I'd like to actually edit 

pg configuration file to change the message.

The actual source looks pretty straightforward. I'm wondering whether pg 

style would suggest to write motd != NULL instead of just motd.

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].

On Sat, Apr 3, 2021, at 17:50, Fabien COELHO wrote:

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?

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.

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 COELHO <coelho@cri.ensmp.fr> writes:

>>> 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 \([a-z]* != NULL &&
>> 119 results in 72 files
>>
>> if \([a-z]* &&
>> 936 results in 311 files
>
> 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".

Looking specifically at code checking an expression before dereferencing
it, we get:

$ ag '(?:if|Assert)\s*\(\s*(\S+)\s*&&\s*\1->\w+' | wc -l
247

$ ag '(?:if|Assert)\s*\(\s*(\S+)\s*!=\s*NULL\s*&&\s*\1->\w+' | wc -l
74

So the shorter 'foo && foo->bar' form (which I personally prefer) is
considerably more common than the longer 'foo != NULL && foo->bar' form.

- ilmari
-- 
"The surreality of the universe tends towards a maximum" -- Skud's Law
"Never formulate a law or axiom that you're not prepared to live with
 the consequences of."                              -- Skud's Meta-Law

Fabien COELHO <coelho@cri.ensmp.fr> writes:

>>> 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 \([a-z]* != NULL &&

>> 119 results in 72 files

>>

>> if \([a-z]* &&

>> 936 results in 311 files

>

> 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".

Looking specifically at code checking an expression before dereferencing

it, we get:

$ ag '(?:if|Assert)\s*\(\s*(\S+)\s*&&\s*\1->\w+' | wc -l

247

$ ag '(?:if|Assert)\s*\(\s*(\S+)\s*!=\s*NULL\s*&&\s*\1->\w+' | wc -l

74

So the shorter 'foo && foo->bar' form (which I personally prefer) is

considerably more common than the longer 'foo != NULL && foo->bar' form.