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 1qdbQA-0045Oo-FZ for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Sep 2023 19:09:06 +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 1qdbQ7-004BMK-Q1 for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Sep 2023 19:09:03 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qdbQ7-004BM1-Ba for pgsql-hackers@lists.postgresql.org; Tue, 05 Sep 2023 19:09:03 +0000 Received: from mail-pf1-x434.google.com ([2607:f8b0:4864:20::434]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qdbPz-003FhL-4S for pgsql-hackers@postgresql.org; Tue, 05 Sep 2023 19:09:02 +0000 Received: by mail-pf1-x434.google.com with SMTP id d2e1a72fcca58-68becf931bfso1846322b3a.0 for ; Tue, 05 Sep 2023 12:08:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=j-davis-com.20230601.gappssmtp.com; s=20230601; t=1693940933; x=1694545733; 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=Nce6DlGhb1vRYqM/fqpHJbc4yoEGB8DSOKGxvCzTj4M=; b=jjxvebZPb3atAsvVZBMF4bl1BPGr/vDN6532WzwBQMMS3k5m/McvfeiwEe+NvgvJTE HTxsVMtchLKeM0sEf6v4r66oXz90QHA94vizFU30KcxXhTtoDGsVURTgGTEMj1mA5Pmo EkkaXKpQG0UCb0S7ETvJ4JmDZ54KbPC+wrMB7vDMKeztmUJkI+C+/VS/5S5xtsB2ZDIq 82lNj8ILzna5n09faNU+OzgkV+p2x22MvxFSRbBjc1IdRIzUBWoC/I3FHVvcOF+sC+ht uhc5fdiKWNiIxC9oPTdgjKrZ/gnOwe219no+fqFzmQWrgyf8fkPpIo3jmF1Bkht8UYIl Pikw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1693940933; x=1694545733; 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=Nce6DlGhb1vRYqM/fqpHJbc4yoEGB8DSOKGxvCzTj4M=; b=ljnLV0Fj3ZovXMSmH5jidqh06eTnCXSgKPL8FfH4vOi4KFXNPO8WkbCH7povjwCaa8 PyzdCA8Oha4ekQEqFgdQV3bbgIVN21EgcFnND1jXW4E9VeqIxmqJhXbB1uzaTqcAFSJG b0i+o4RweaeXSiHzr5vUzjXbsO0qbF9Dd5Ciiq17qEDDhXXGfPNCEeKIjNMeYR5/JFRI EslVAGcGVAviGsuGRZam/175DGdxEmWkG59t3qgrD+3lRtMTK5aiPpybz+vIpAlth5RH klH3goKLY/oKtpFttiRvZQkoGfaUI5z/jg6NXQt6eHf63AcSlsAQlY4LGekAPfRvdIlk Enxg== X-Gm-Message-State: AOJu0YxZDK0DIrRlct4fj8tIhg9vhNUAHoTDULK9MQd0jIf2x3LF/Tu4 muvoYjFv1CixMM6ryoBbzL7iFg== X-Google-Smtp-Source: AGHT+IFtLPX92zerWjF/rq6KXlopc18SjiJpwl4bATYKWOdNusPEsaRZPPCkiyB/JtUVwRyM3SBPfw== X-Received: by 2002:aa7:9014:0:b0:68e:2cc4:c720 with SMTP id m20-20020aa79014000000b0068e2cc4c720mr302436pfo.12.1693940932786; Tue, 05 Sep 2023 12:08:52 -0700 (PDT) Received: from [172.18.4.23] ([12.126.244.130]) by smtp.gmail.com with ESMTPSA id g20-20020a62e314000000b00688214cff65sm9372689pfh.44.2023.09.05.12.08.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Sep 2023 12:08:52 -0700 (PDT) Message-ID: <05ae37abb207cd6bf6b126780024692d91402b0b.camel@j-davis.com> Subject: Re: [17] CREATE SUBSCRIPTION ... SERVER From: Jeff Davis To: Ashutosh Bapat Cc: Joe Conway , pgsql-hackers@postgresql.org Date: Tue, 05 Sep 2023 12:08:52 -0700 In-Reply-To: References: <149ff9264db27cdf724b65709fbbaee4bf316835.camel@j-davis.com> <830a2bc6cbbb2e6e01c6c0d9f31f320822e10603.camel@j-davis.com> <433d0845248e86c0317d9d396926182cfe157340.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 Mon, 2023-09-04 at 18:01 +0530, Ashutosh Bapat wrote: > Why do we need to re-check parameters constantly? We will need to > restart subscriptions which are using the user mapping of FDW when > user mapping or server options change. "Constantly" was an exaggeration, but the point is that it's a separate validation step after the ALTER SERVER or ALTER USER MAPPING has already happened, so the subscription would start failing. Perhaps this is OK, but it's not the ideal user experience. Ideally, the user would get some indication from the ALTER SERVER or ALTER USER MAPPING that it's about to break a subscription that depends on it. > I didn't understand your worry about circumventing password_required > protection. If the subscription doesn't do its own validation, and if the FDW doesn't ensure that the password is set, then it could end up creating a creating a connection string without supplying the password. > We don't need to if we allow any FDW (even if non-postgreSQL) to be > specified there. OK, so we could have a built-in FDW called pg_connection that would do the right kinds of validation; and then also allow other FDWs but the subscription would have to do its own validation. Regards, Jeff Davis