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.94.2) (envelope-from ) id 1uIa7m-007coT-8P for pgsql-hackers@arkaria.postgresql.org; Fri, 23 May 2025 21:40:18 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uIa7k-006gC0-TL for pgsql-hackers@arkaria.postgresql.org; Fri, 23 May 2025 21:40:16 +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.94.2) (envelope-from ) id 1uIa7k-006g76-Jf for pgsql-hackers@lists.postgresql.org; Fri, 23 May 2025 21:40:16 +0000 Received: from 003.mia.mailroute.net ([199.89.3.6]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uIa7h-000Zu5-0N for pgsql-hackers@postgresql.org; Fri, 23 May 2025 21:40:15 +0000 Received: from localhost (localhost [127.0.0.1]) by 003.mia.mailroute.net (Postfix) with ESMTP id 4b3z8r33dmzlgqyV for ; Fri, 23 May 2025 21:40:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=acm.org; h= content-transfer-encoding:content-type:content-type:mime-version :user-agent:date:date:message-id:subject:subject:from:from :received:received; s=mr01; t=1748036411; x=1750628412; bh=NEy77 IUV7xSfx8haGbqCFPNTJIwfkj59HO3aUtYVLs0=; b=exvZtb+wxIrMhesSnPRdy 7PChB8pE69LB5oHVZ2xbR14nwQbTP8Noo+dlhYe3Z7POQyDjfFcunnJLfAv35PMQ Pdzti7dLpZtypGpW8awPHN5LmR+NwzGoNyyifIVS+hbsPjc9Z37bXYRx7Vih1CP5 vpd4KaFS6+9QDBpL6yMD0uPhCHZmXtKvyxgRaHPmTIlNERzoKqTxfmDarQixrxDy rKhNzEHToOcLYNLFpLOHdxDnTbXfwYHAsPgo2500TstT0M4k03ZgAYuq5EQYWHEZ zPK9TPxX3pYkSgCtVZAIYeNClqk6mwVMiQM2yjF0Y1Nm4zeFUonfxrd3/SPi5qCU A== X-Virus-Scanned: by MailRoute Received: from 003.mia.mailroute.net ([127.0.0.1]) by localhost (003.mia [127.0.0.1]) (mroute_mailscanner, port 10029) with LMTP id 8eeuaWyZRRcg for ; Fri, 23 May 2025 21:40:11 +0000 (UTC) Received: from [73.103.120.3] (c-73-103-120-3.hsd1.in.comcast.net [73.103.120.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jcflack@acm.org) by 003.mia.mailroute.net (Postfix) with ESMTPSA id 4b3z8q31M5zlvq6w for ; Fri, 23 May 2025 21:40:09 +0000 (UTC) To: PostgreSQL Hackers From: Chapman Flack Subject: tighten generic_option_name, or store more carefully in catalog? X-Enigmail-Draft-Status: N1110 Message-ID: <6830EB30.8090904@acm.org> Date: Fri, 23 May 2025 17:40:00 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, generic_option_name is a ColLabel, therefore a fully general SQL identifier. But a command like CREATE FOREIGN DATA WRAPPER w ... OPTIONS ("a=b" 'c=d') stores {a=b=c=d} in fdwoptions, from which the original intent can't be recovered. Should generic_option_name be restricted to be a regular identifier, or allowed to be a delimited identifier but with = forbidden within it, or should it be represented as delimited in the catalog when necessary so it can be recovered faithfully? SQL rules would also make its case-sensitivity dependent on faithfully recovering whether it was delimited or not. Regards, -Chap