Re: Surprising behaviour of \set AUTOCOMMIT ON - Mailing list pgsql-hackers

From Daniel Verite
Subject Re: Surprising behaviour of \set AUTOCOMMIT ON
Date
Msg-id f2cb5838-0ee9-4fe3-acc0-df77aeb7d4c7@mm
Whole thread Raw
In response to Re: Surprising behaviour of \set AUTOCOMMIT ON  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Surprising behaviour of \set AUTOCOMMIT ON  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
    Tom Lane wrote:

> I think changing the hook API is a pretty reasonable thing to do here
> (though I'd make it its own patch and then add the autocommit change
> on top).  When was the last time you actually wanted to set VERBOSITY
> to "fubar"?

It looks easy to make the hooks return a bool, and when returning false,
cancel the assignment of the variable.
I volunteer to write that patch.

It would close the hazard that exists today of an internal psql flag
getting decorrelated from the corresponding variable, due to feeding
it with a wrong value, or in the case of autocommit, in the wrong
context.

Also with that, the behavior of ParseVariableBool() assuming "on"
when it's being fed with junk could be changed. Instead it could just
reject the assignment rather than emit a warning, and both
the internal flag and the variable would keep the values they had
at the point of the bogus assignment.

Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite



pgsql-hackers by date:

Previous
From: Jesper Pedersen
Date:
Subject: Re: Hash Indexes
Next
From: Heikki Linnakangas
Date:
Subject: Re: [COMMITTERS] pgsql: Support OpenSSL 1.1.0.