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 1rQMeI-000iYz-St for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Jan 2024 07:17:15 +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 1rQMeF-000xLB-DX for pgsql-hackers@arkaria.postgresql.org; Thu, 18 Jan 2024 07:17:11 +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 1rQMeE-000xL2-VQ for pgsql-hackers@lists.postgresql.org; Thu, 18 Jan 2024 07:17:11 +0000 Received: from mail-ot1-x32e.google.com ([2607:f8b0:4864:20::32e]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rQMeA-00278s-3z for pgsql-hackers@postgresql.org; Thu, 18 Jan 2024 07:17:09 +0000 Received: by mail-ot1-x32e.google.com with SMTP id 46e09a7af769-6dddf12f280so6662408a34.0 for ; Wed, 17 Jan 2024 23:17:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20230601.gappssmtp.com; s=20230601; t=1705562225; x=1706167025; darn=postgresql.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=pmQLj3dn7sjXi9LtHd3lVaInR5KItIlbAHah4VtBrcM=; b=K4veJInMBjNYVjgTG2AvwFg15ios96fUp1zj4U9UZO1ZEVbOHPkdjVdggiV/JFHMYM fgkpSUlaMjB/7FYkYwFFOwn1bQ4+OTZLX5Bsc1EzcHp4uWiEeO8izpaEV0veRe4qmBma Qv/So5w1Ql86+FOMhC6I+1HUpc3Uj7XCuxiljP44OiQ2mFWV2tjhotFx5Dxkbf7H5FGY zD5etO6UE12tu/XcAKC5UwwOVu3mzVCgVgn1564PuDyG1oITEQlLlxBtpqKjKMNE6hz0 EPbdY/0zCIrw1c2F4mhES9aMgOqDYi4P9p7XlUDBu4tWLyuKmHGie0DBY9kLPKRddV29 orpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705562225; x=1706167025; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=pmQLj3dn7sjXi9LtHd3lVaInR5KItIlbAHah4VtBrcM=; b=mIH+tP2TC7xhjlWadbb4b0W6rZoelIyBK9hGtofMGmxKwuviwaUbGZqtP+/1Mn9egc NwtruvlLzxx4qilZBOpTO1Zu8w2sPXdIEj4u52G8O1Kq9cpY4pBbRtwt6R5vl8yHAg2S KE9lcWvBVeTRDrEiCIpmuji60Od8O/JyYOxPvjMJYn07QO2mhPxgZbFWSpWxZns+rUbF R8/z0x+e5vHbcX1EyuV6Y3/zl4aT4kNo9mIeLT3Br3sH3IrGAxcRHN8yrbjNFjk93hxk hFqJqfaDxmjH0mkKYmhHKetFkYm8uG45R+PqU8gsqcwgmbptPM02FUCgiGY6zUlRjfaa xL7A== X-Gm-Message-State: AOJu0YxLQUc1imeqjHpfCpBKksKvpj0HLpyg/OCrXK4WlQCMhB4eF53l /3buVPVArU62yPxbB45uIHLVIN8n/wh0V6cY/VHIHbQ2IK9RzNexPTDU3nhDB7sHm4FAZb0+/Oe MBg== X-Google-Smtp-Source: AGHT+IHDMuUh8lLAhTc5WE7/KRMANb+dRyJEOdnw+Xkoc2JbMKWrq7h8YUBKUK037rypqPsGB14x9Q== X-Received: by 2002:a05:6830:2685:b0:6e0:ce4c:dcf0 with SMTP id l5-20020a056830268500b006e0ce4cdcf0mr500392otu.44.1705562225241; Wed, 17 Jan 2024 23:17:05 -0800 (PST) Received: from jeff-laptop.lan (c-76-102-242-158.hsd1.ca.comcast.net. [76.102.242.158]) by smtp.gmail.com with ESMTPSA id ca28-20020a056a02069c00b005bdd8dcfe19sm701720pgb.10.2024.01.17.23.17.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Jan 2024 23:17:04 -0800 (PST) Message-ID: <8c0db5db939a71dea0c9307207aa0842f84c352c.camel@j-davis.com> Subject: Re: [17] CREATE SUBSCRIPTION ... SERVER From: Jeff Davis To: Bharath Rupireddy Cc: Ashutosh Bapat , Joe Conway , pgsql-hackers@postgresql.org Date: Wed, 17 Jan 2024 23:17:01 -0800 In-Reply-To: References: <149ff9264db27cdf724b65709fbbaee4bf316835.camel@j-davis.com> <830a2bc6cbbb2e6e01c6c0d9f31f320822e10603.camel@j-davis.com> <433d0845248e86c0317d9d396926182cfe157340.camel@j-davis.com> <05ae37abb207cd6bf6b126780024692d91402b0b.camel@j-davis.com> <93392ffa941ab0d436e19e0ab5d04d0e42c02d3f.camel@j-davis.com> <26be917cb07b6aa3ef5dd15f6b59d1b375ece6e8.camel@j-davis.com> <55201bd916e748acfc754c8f95880dae8e4e5ed0.camel@j-davis.com> <2a89b14a2b1622bffb8b137ca1f9ab7866f2d2b9.camel@j-davis.com> <61831790a0a937038f78ce09f8dd4cef7de7456a.camel@j-davis.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4-0ubuntu2 MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, 2024-01-16 at 09:23 +0530, Bharath Rupireddy wrote: > 1. > May be a more descriptive note is > worth here instead of just saying "Load the library providing us > libpq calls."? OK, will be in the next patch set. > 2. Why not typedef keyword before the ConnectionOption structure? Agreed. An earlier unpublished iteration had the struct more localized, but here it makes more sense to be typedef'd. > 3. > +static const struct ConnectionOption * > +libpqrcv_conninfo_options(void) >=20 > Why is libpqrcv_conninfo_options returning the const > ConnectionOption? I did that so I could save the result, and each subsequent call would be free (just returning the same pointer). That also means that the caller doesn't need to free the result, which would require another entry point in the API. > Is it that we don't expect callers to modify the result? I think it's > not needed given the fact that PQconndefaults doesn't constify the > return value. The result of PQconndefaults() can change from call to call when the defaults change. libpqrcv_conninfo_options() only depends on the available option names (and dispchar), which should be a static list. > 4. > +=C2=A0=C2=A0=C2=A0 /* skip options that must be overridden */ > +=C2=A0=C2=A0=C2=A0 if (strcmp(option, "client_encoding") =3D=3D 0) > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return false; > + >=20 > Options that must be overriden or disallow specifiing > "client_encoding" in the SERVER/USER MAPPING definition (just like > the > dblink)? I'm not quite sure of your question, but I'll try to improve the comment. > 5. > "By using the correct libpq options, it no longer needs to be > deprecated, and can be used by the upcoming pg_connection_fdw." >=20 > Use of postgresql_fdw_validator for pg_connection_fdw seems a bit odd > to me. I don't mind pg_connection_fdw having its own validator > pg_connection_fdw_validator even if it duplicates the code. To avoid > code duplication we can move the guts to an internal function in > foreign.c so that both postgresql_fdw_validator and > pg_connection_fdw_validator can use it. This way the code is cleaner > and we can just leave postgresql_fdw_validator as deprecated. Will do so in the next patch set. Thank you for taking a look. Regards, Jeff Davis