Re: Emit a warning if the extension's GUC is set incorrectly

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: peter(dot)eisentraut(at)enterprisedb(dot)com
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Shinya11(dot)Kato(at)oss(dot)nttdata(dot)com, masao(dot)fujii(at)oss(dot)nttdata(dot)com, bharath(dot)rupireddyforpostgres(at)gmail(dot)com, daniel(at)yesql(dot)se, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Emit a warning if the extension's GUC is set incorrectly
Date: 2021-12-21 18:33:49
Message-ID: 116024.1640111629@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:
> 0003 looks to me like it was superseded by 75d22069e. I do not
> particularly like that patch though; it seems both inefficient
> and ill-designed. 0003 is adding a check in an equally bizarre
> place. Why isn't add_placeholder_variable the place to deal
> with this? Also, once we know that a prefix is reserved,
> why don't we throw an error not just a warning for attempts to
> set some unknown variable under that prefix? We don't allow
> you to set unknown non-prefixed variables.

Concretely, I think we should do the attached, which removes much of
75d22069e and does the check at the point of placeholder creation.
(After looking closer, add_placeholder_variable's caller is the
function that is responsible for rejecting bad names, not
add_placeholder_variable itself.)

This also fixes an indisputable bug in 75d22069e, namely that it
did prefix comparisons incorrectly and would throw warnings for
cases it shouldn't. Reserving "plpgsql" shouldn't have the effect
of reserving "pl" as well.

I'm tempted to propose that we also rename EmitWarningsOnPlaceholders
to something like MarkGUCPrefixReserved, to more clearly reflect
what it does now. (We could provide the old name as a macro alias
to avoid breaking extensions needlessly.)

regards, tom lane

Attachment Content-Type Size
fix-guc-prefix-checking.patch text/x-diff 6.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2021-12-21 18:58:39 Re: pg14 psql broke \d datname.nspname.relname
Previous Message John Naylor 2021-12-21 17:36:20 Re: do only critical work during single-user vacuum?