Обсуждение: Re: [HACKERS] Improvements in psql hooks for variables

"Daniel Verite" <daniel@manitou-mail.org> writes:
> Setting ENCODING has no effect, like DBNAME, USER, HOST and PORT.
> In a way, it's a read-only variable that's here to inform the user,
> not as a means to change the encoding (\encoding does that and
> has proper support for tab completion)

Right.

> What we could do as of this patch is emit an error when we try
> to change ENCODING, with a hook returning false and
> a proper error message hinting to \encoding.

I think that the current behavior is intentional: it avoids making
those variables reserved.  That is, if you're unaware that psql
sets them and try to use them for your own purposes, it will work.

However, it only really works if psql never overwrites the values
after startup, whereas I believe all of these are overwritten by
a \c command.

So maybe it's more user-friendly to make these variables fully
reserved, even at the risk of breaking existing scripts.  But
I don't think it's exactly an open-and-shut question.
        regards, tom lane

    Tom Lane wrote:

> However, it only really works if psql never overwrites the values
> after startup, whereas I believe all of these are overwritten by
> a \c command.

Yes, there are reset to reflect the properties of the new connection.

> So maybe it's more user-friendly to make these variables fully
> reserved, even at the risk of breaking existing scripts.  But
> I don't think it's exactly an open-and-shut question.

You mean if we make that fail:    \set ENCODING UTF8
it's going to make that fail too: SELECT something AS "ENCODING"[,...]    \gset
and I agree it's not obvious that this trade-off has to be
made. Personally I'm fine with the status quo and will
not add that hook into the patch unless pressed to.

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