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 1vsIcM-00FNz9-1q for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Feb 2026 10:47:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vsIcL-009kji-1N for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Feb 2026 10:47:45 +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.96) (envelope-from ) id 1vsIcL-009kjX-0U for pgsql-hackers@lists.postgresql.org; Tue, 17 Feb 2026 10:47:45 +0000 Received: from mail-ed1-x52e.google.com ([2a00:1450:4864:20::52e]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vsIcJ-00000001BJ1-1a36 for pgsql-hackers@lists.postgresql.org; Tue, 17 Feb 2026 10:47:45 +0000 Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-65a26c220b6so5375510a12.0 for ; Tue, 17 Feb 2026 02:47:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771325262; cv=none; d=google.com; s=arc-20240605; b=ghvytjki03S+gfMI1xnfmiOgypag6JITL4o54lNVxr/2Sbo/7HlacTE/Yz1ymZvwAM lE1buqyI1Avc42aphZUYwCRQCPjrnXee+EqzGoDPo5cWdR9AWyvG6tTPXq/mAyBT6un6 UGoOKuoKmGXVe6kV81rUb0Y8aYmk12ED46FR6U1OymTAbSDhBIbKdJ6HPuTYAueEjyES hQI8YPbU8VMXXmZlp9TS35EddunGYmljmLqKlOtpvw93xPzhICcF122BrfLr9S9/kyLP sKcWN/PmWmkRxlaRXfMtpvd8c987eYqBsCki0Ts1Tj0OZJcm+tvh3L5Cjs7Pxgjrh85n 4a2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=e+sXmh5i7/Uo7MeE+jfkgGHlJZWPrlpbJIzObA249dg=; fh=t0b2n1E3t1YOWEvQkE4VAfG4nh2ZKiDROuy8N6WTdDo=; b=evFoQMflZrGpWhd0rWMBVfDjixMpgHw08p3k2tpeYkQzYVAONwGBONx4Iur46k0fJ0 kK2dkE1UPbIZekVEL4HPnMM8zZ2AKJiYJDXJrFtYCCPpAX/vTRUt1bZQhnYna7TmLTUK VdfsstLk+tItZMq2HxTNhvOH7bYefqToe7/pC9k9ZC/ObuexO5G7CemjwxoLdhcmKy/W kn17Jp/wA/Jazabm0ch4uWg3z5blJnt8ccyMGDNMrdfnc1sX8mEG0MKGs7s/GUOmyjzE 1Ii9HG/L/LC0n3/PR0MuVtmz4yuS9k+slKd8VYUb+4jFblW2Tfh7TgiZEBW0SZ8mzTuz 1otQ==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771325262; x=1771930062; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=e+sXmh5i7/Uo7MeE+jfkgGHlJZWPrlpbJIzObA249dg=; b=ODyXYY+tO7kp7cuUxXfmyGb3qe6SuqavirfNJ7xrvUj2COwb8zy2q8pQQifPZ+Gf07 F0ifLRmXnnvJxfaALcOQ8D1pB0B1kQffUr+JDhzcicl9D5qn3Nu3zerUWUeta7vQ5TKx v+w5amzb3D0uweNtuDOqpyFoPzKP6HZK01I/WRzH+38WlYMyPiXpl3duE72JTl+p/lIc SCdpO2cl4BL7XfFC7i25Lnkpuw2w4uKXM5D7Oc7pW1W5pIBJpeNA5VSJBT5PSgP7cEug FcFIwBAoOixL2L0uCHKI6XxSxrxKXG6XFQZzXc8Y/ALAuHo/iEByu9P1EYgFB1EDWPhj 2F1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771325262; x=1771930062; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=e+sXmh5i7/Uo7MeE+jfkgGHlJZWPrlpbJIzObA249dg=; b=EW630wf+8bOuyiJL9fSs4mbyB6PKvNbG+PmuXrBB3erwp3KKUhwm0VI4LTkr/8zo+r qWAiCva17L4esDVf0okO7P/0Qzd2oLtnJb9jmV+DLqkudzYA5Y/mgVp1PTaWGtUcOfQq un6LUHfB/cbhNoywJ0P+8XJJgx2FoAzcNKl6q1cfcrbreuvAOzJ5bm9C3fjvuUyHcOS2 mfc0lHhydhKQkMiHZklpvVyjWjyYZKzv6Y5lUCuGwbNvxJvYFLwHrkueQq+3i1jNb3bw KJ9FMjf+QmlFYT+o6WfwNov9rHHrGU52eOcxFx2ds81gmj9/xiG8aoXa2DzaHNH3RWZF W7gw== X-Forwarded-Encrypted: i=1; AJvYcCXBa3SjkwnU9kB13z6P2XFA1XrBqx/+6jvkeGXQjJBt6uqHcEeSWt1Xzt59JAXdbgxCEf3mDIrun55/1NMx@lists.postgresql.org X-Gm-Message-State: AOJu0Yw9dSVlZmIWliJQrS3FRGhpMIx7B0dFx+Xh/qJ3FQrKWC6n8I5S ysP3tA2zyNeE/y6rtV1FC5luM6NcXb9e4eCWV7P/dyn1Dy8qDJoiPiKmBe9Bf9PDrtA4zD8pOlz kMFqWG04pLw2Tkcng8zqi/cvew71MSOruRoVI X-Gm-Gg: AZuq6aIjKickzwuWRXJHtBPnDk4N5Pu25XGLvhvUAreldDO4C5AASnjwhF/8ulbQlWZ ZDDZgkO/9ECibjxd2MphW6ZlOVviX4/RvSis6Dp3+e1hgbsF7heJNbTZpOmLt/udE5HUOBiIN4Q EI0UyG1sDW65f1lb5BNAsYEOWmy/3MJz7vjI/8ovB6Kj+tn3STN+ZGAyJGHQwJXQWgVA/+rfyIz pjG3m1OKe67tz7ePlQV1A3G4nLMq6rh+aVDdLli5BbP1orMjJc8UeOikTFGHg7MpYcsIkX+MjVP v78J75I= X-Received: by 2002:a17:907:2d8c:b0:b86:edb9:c01b with SMTP id a640c23a62f3a-b8fb4146f24mr760836866b.8.1771325262176; Tue, 17 Feb 2026 02:47:42 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: VASUKI M Date: Tue, 17 Feb 2026 16:17:50 +0530 X-Gm-Features: AaiRm51ok1GPBuD8xUBZ92GQ_ceumWLTzzeLG4GahPzkLBCPBTggpZ6POpi0Ut0 Message-ID: Subject: Re: [OAuth2] Infrastructure for tracking token expiry time To: Zsolt Parragi Cc: Ajit Awekar , PostgreSQL Hackers Content-Type: multipart/alternative; boundary="00000000000008a6a5064b02cd5f" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000008a6a5064b02cd5f Content-Type: text/plain; charset="UTF-8" Hi All, I see the concern about keeping the validator API generic and not implicitly favoring JWT-style providers. The callback-based approach does seem more flexible, especially for opaque tokens or providers supporting revocation, where validity cannot be represented as a fixed timestamp. Perhaps one possible direction could be to support both: An optional expiry timestamp for simple/static cases. An optional callback (e.g., expired_cb) for dynamic validation. This would allow JWT-based validators to remain lightweight while enabling more complex providers to implement custom revalidation logic. If enforcement is planned at statement start, integrating the callback mechanism in the same patch might also clarify the intended semantics. Best regards, Vasuki M C-DAC,Chennai --00000000000008a6a5064b02cd5f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I see the concern about keeping the validat= or API generic and not implicitly favoring JWT-style providers.
The call= back-based approach does seem more flexible, especially for opaque tokens o= r providers supporting revocation, where validity cannot be represented as = a fixed timestamp.
Perhaps one possible direction could be to support bo= th:

An optional expiry timestamp for simple/static cases.

An = optional callback (e.g., expired_cb) for dynamic validation.

This wo= uld allow JWT-based validators to remain lightweight while enabling more co= mplex providers to implement custom revalidation logic.
If enforcement i= s planned at statement start, integrating the callback mechanism in the sam= e patch might also clarify the intended semantics.

Best regards,
= Vasuki M
C-DAC,Chennai
--00000000000008a6a5064b02cd5f--