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 |
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? |