Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vlQfs-00Bs2o-1s for pgsql-hackers@arkaria.postgresql.org; Thu, 29 Jan 2026 11:59:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vlQfr-008S9v-0a for pgsql-hackers@arkaria.postgresql.org; Thu, 29 Jan 2026 11:58:59 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vlQfq-008S8n-2l for pgsql-hackers@lists.postgresql.org; Thu, 29 Jan 2026 11:58:59 +0000 Received: from mail.nataraj.su ([168.119.121.177]) by makus.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vlQfo-002uTb-0D for pgsql-hackers@lists.postgresql.org; Thu, 29 Jan 2026 11:58:58 +0000 Received: from [0.0.0.0] (static.76.198.203.116.clients.your-server.de [116.203.198.76]) by mail.nataraj.su (Postfix) with ESMTPSA id 85191141DDD; Thu, 29 Jan 2026 14:58:53 +0300 (MSK) Message-ID: Date: Thu, 29 Jan 2026 14:58:52 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Custom oauth validator options To: Zsolt Parragi , =?UTF-8?Q?=C3=81lvaro_Herrera?= Cc: Jacob Champion , VASUKI M , PostgreSQL Hackers , david.g.johnston@gmail.com, Robert Haas , myon@debian.org References: <202601281620.m3hrqtih5b2w@alvherre.pgsql> Content-Language: en-US, ru-RU From: Nikolay Shaplov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 28.01.2026 22:21, Zsolt Parragi wrote: >> but I wonder if this is something we >> should attempt in the context of the larger refactoring done by the >> patch series here, > That patch series is interesting but it is about SQL (table, index, > operator) options, while this is about guc variable validation and > extension. These seem unrelated to me. This patch suggests context independent API for managing extension defined sets of options. It is used for relation options and similar options, but cat be also used for any options sets, may be with small modifications. GUC options are almost same options as relation options. That is why, I guess, Alvaro suggested you to look at this patch. And I agree with him. Please have a look at src/backend/access/common/options.c in that patch. I almost sure this code can be reused for GUC options too. Whole https://commitfest.postgresql.org/patch/4688/ is a bit outdated, and need rebase, but options.c from it is as good as it was before. And we've just recently committed a small fix that have been blocking 4688's patch rebase. I have plans to rebase it in not so distant future. It you find it useful for your tasks and even would like to join to review (at least for options.c part) I would do it with higher priority. (but it is still my weekend-days project, so it can't be extremely fast)