Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nHhpW-0008PH-3C for pgsql-hackers@arkaria.postgresql.org; Wed, 09 Feb 2022 07:55:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nHhpU-0002m2-Jk for pgsql-hackers@arkaria.postgresql.org; Wed, 09 Feb 2022 07:55:56 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nHhpU-0002lP-7p for pgsql-hackers@lists.postgresql.org; Wed, 09 Feb 2022 07:55:56 +0000 Received: from mail-pj1-x102f.google.com ([2607:f8b0:4864:20::102f]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nHhpS-0001g3-3z for pgsql-hackers@postgresql.org; Wed, 09 Feb 2022 07:55:55 +0000 Received: by mail-pj1-x102f.google.com with SMTP id om7so1427474pjb.5 for ; Tue, 08 Feb 2022 23:55:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:message-id:to:cc:subject:from:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=OtvNmqxFU/yLRuXE02nW91oseKiceCns5OCGzvyQyUU=; b=eGOe+YbvxIu8C4KL6r1tRg+WZ42AJCgdWSaaAXUawSdpNpAxhA/IEcx+sdVQ2vuGLy 7zdW2ISAinfL9ayLi7rJf3ucUGVRyUpXBgsGmHUMg6ISZQAYRcb3OEWmZz93WHlBzPMT u3Tep5Y7Xvi3LQUEHJjvAs1WzvKM8eOk1OdH0W90vtZmZ5ZogsO8Mm1uGamfBxux9EiO R98JKqwGNzIrAqXItnxuc4lgbXNNEKW2LAJxFPUI7CMvtuau53AUwnEpb0Lxq2osAQZJ qb/ebc4yg8ca4IEH+vwc0jaJVGVLsiy/0a5BwXCo4l2D6wtcKRucoCZUT6YqLv5ba5cV es3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:message-id:to:cc:subject:from:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=OtvNmqxFU/yLRuXE02nW91oseKiceCns5OCGzvyQyUU=; b=kciv+NvDNy7DesymD7zXCzrH4q9taW2NLigMSDC8IVOPA639R5NtbKajPfVrpbIKBy M6yrndAIEY/BNZAC25BFHt1ZhkBw/4i7mAQpY4LvVqItxxw9JoJM4ivEv5TRKYRj11eJ PzogSOExDqFM/6Kf2D4D1iajUAF3+bZv374jbnrU2krNZrX+XMUcr55/W/8Uz3G9ww3e KciXEzwz2OoeizeVIUXfFywiFY2W9wm1bzoeSpGNcGnzfELIqPkyttIXmpj7yATqCfZa cbWiXTvfcI4nWbZl4Eete1aT1glkDLMUbKX7Xzzc6PVqRGFYQvytfWO5f3l+bG4q5aFw BUkw== X-Gm-Message-State: AOAM533fTJyOwQys9IdUML0o4S5vLBjh7/OTLDBE5f3BJuQyf544Spuy YlZVeBi75kz2e8iTPkt8ngk= X-Google-Smtp-Source: ABdhPJwIE4oBX12etHOjrmxiMe73Vn4H2sPe3/fsudd3EAo4t/bsVfFc4sypsKkoNMRdtQE7zyH22Q== X-Received: by 2002:a17:902:d4ce:: with SMTP id o14mr962441plg.14.1644393351743; Tue, 08 Feb 2022 23:55:51 -0800 (PST) Received: from localhost (KD036014041111.ppp-bb.dion.ne.jp. [36.14.41.111]) by smtp.gmail.com with ESMTPSA id u17sm9552279pfi.163.2022.02.08.23.55.50 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Tue, 08 Feb 2022 23:55:51 -0800 (PST) Date: Wed, 09 Feb 2022 16:55:49 +0900 (JST) Message-Id: <20220209.165549.93763781529472908.horikyota.ntt@gmail.com> To: masao.fujii@oss.nttdata.com Cc: pgsql-hackers@postgresql.org Subject: Re: Support escape sequence for cluster_name in postgres_fdw.application_name From: Kyotaro Horiguchi In-Reply-To: References: <1041dc9a-c976-049f-9f14-e7d94c29c4b2@oss.nttdata.com> <20220127.171042.1194024926941192601.horikyota.ntt@gmail.com> User-Agent: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Sorry for missing this. At Thu, 27 Jan 2022 19:26:39 +0900, Fujii Masao wrote in > > On 2022/01/27 17:10, Kyotaro Horiguchi wrote: > > I don't object to adding more meaningful replacements, but more escape > > sequence makes me anxious about the increased easiness of exceeding > > the size limit of application_name. > > If this is really an issue, it might be time to reconsider the size > limit of application_name. If it's considered too short, the patch > that enlarges it should be proposed separately. That makes sense. > > Considering that it is used to > > identify fdw-initinator server, we might need to add padding (or > > rather truncating) option in the escape sequence syntax, then warn > > about truncated application_names for safety. > > I failed to understand this. Could you tell me why we might need to > add padding option here? My point was "truncating" option, which limits the length of the replacement string. But expanding the application_name limit is more sensible. > > Is the reason for 'C' in upper-case to avoid possible conflict with > > 'c' of log_line_prefix? > > Yes. > > > I'm not sure that preventive measure is worth > > doing. Looking the escape-sequence spec alone, it seems to me rather > > strange that an upper-case letter is used in spite of its lower-case > > is not used yet. > > I have no strong opinion about using %C. If there is better character > for the escape sequence, I'm happy to use it. So what character is > more proper? %c? I think so. > > Otherwise all looks fine to me except the lack of documentation. > > The patch updated postgres-fdw.sgml, but you imply there are other > documents that the patch should update? Could you tell me where the > patch should update? Mmm. I should have missed that part. regards. -- Kyotaro Horiguchi NTT Open Source Software Center