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 1tBcmB-0053TD-4f for pgsql-general@arkaria.postgresql.org; Thu, 14 Nov 2024 16:32:58 +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 1tBcm8-005dyX-Hs for pgsql-general@arkaria.postgresql.org; Thu, 14 Nov 2024 16:32:57 +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 1tBcm8-005dyP-6a for pgsql-general@lists.postgresql.org; Thu, 14 Nov 2024 16:32:56 +0000 Received: from mail-ot1-x32f.google.com ([2607:f8b0:4864:20::32f]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1tBcm3-001vYj-Tt for pgsql-general@lists.postgresql.org; Thu, 14 Nov 2024 16:32:56 +0000 Received: by mail-ot1-x32f.google.com with SMTP id 46e09a7af769-7180ab89c58so449456a34.1 for ; Thu, 14 Nov 2024 08:32:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731601971; x=1732206771; 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=Ip8Ej+ktmA9iEBA8b0vdRfyh/oe1qfGN/G+Hi7lPqGw=; b=NL5mrbJbJXKsRwsWHPDMCrOrOf4SYcq+jCIHFyvqFpNCs7SDpqNlGJsfll6ylLaLTf Chl2+qNrnalEcJkShBsZ6/msFPl8hKy4QshNPCmR1/Ki4CkgGg0VN2ZLwniCLeOVdRRG PWnTO+2wDWRReOtvCONxcoaBgOm2nLXpQIbycDHv0eIvf1JcKKfMrJzlDzVvVDwjXX7p IhSE8BzhjLQiQjq/sUBEr6AV2h8WVrl9T8ZCNBD0g7owHfrzTRg5WH5PW9oPjglhzjMV mlv6S+5c1QhIGhOS1d0FF9tB1iEEB16oHd7dgOH+LCPEcDqvd8QI2WvWNSacKXea77Bl m2ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731601971; x=1732206771; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Ip8Ej+ktmA9iEBA8b0vdRfyh/oe1qfGN/G+Hi7lPqGw=; b=TqpJqBBhWzmKGKjFxIWs8XPagTBJ0CA/CEnW3uQl1NwWucdRnhqmx5+h1eL3BRcM+S 9vCrwaHsuj1UmW8GTLOhjBBD+iNMcjNbbwUZN1WDcV+TmTQumJ9YkM8WBs2wx2SGs3bJ d6HsAm2Khot8U5KVbOgJokGYIEUVC26+WJ3//KFJX3A8Jeq6eWO6kHiUU/oVt6Mn884U 5Ynka2td+Buk4DZobg/POR4DDsRHh+kIX4EMpKiKB4zs5gYGTdfZrD/xT7MVwFPoDjJI +dFU7UhCru7no2R9FMgXfvc+PHyYWGgfCjVNk4km2sMELJRbX3uzpPz996M2DgRSJcpv 7jOQ== X-Gm-Message-State: AOJu0YyNqYbPrx6nxwKS1QrlqS/KcaWf5Qtbt67gegIiN/HXWLptaJNQ c2WhqgfPLilmEklXMEzz3YTwYp/5z0y2h19PbCo8u144xcZNVOaWkpmNMFy56CulXZbXPzHMull n+9RBNCopGmGuV+OPUQkhl1i3yvg= X-Google-Smtp-Source: AGHT+IGDgh0aEAmyFSdXv8d/6zkymOZr5R3vRY53iPQpq41sGTaBTJBL6tfe2amjYnE6bWNGu5lwUf1QziqwI/Sv60c= X-Received: by 2002:a05:6830:6017:b0:718:158d:b5ac with SMTP id 46e09a7af769-71a6020ce21mr8033567a34.20.1731601971108; Thu, 14 Nov 2024 08:32:51 -0800 (PST) MIME-Version: 1.0 References: <242ee502-4b8e-49b5-b2f9-ffba6c678ca2@gmail.com> In-Reply-To: <242ee502-4b8e-49b5-b2f9-ffba6c678ca2@gmail.com> From: Greg Sabino Mullane Date: Thu, 14 Nov 2024 11:32:15 -0500 Message-ID: Subject: Re: question on audit columns To: yudhi s Cc: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000006167110626e20055" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000006167110626e20055 Content-Type: text/plain; charset="UTF-8" As far as the application being able to change those fields itself, you can prevent that via column permissions, by leaving out the four audit columns and doing something like: GRANT INSERT (email, widget_count), UPDATE (email, widget_count) ON TABLE foobar TO PUBLIC; That way, inserts are guaranteed to use the default values of current_timestamp() and current_user. And a BEFORE UPDATE trigger ensures it changes the other two fields via the trigger function only. Cheers, Greg P.S. Also check out https://www.pgaudit.org/ (PGAudit) as an alternative approach, which puts the information into your Postgres logs, rather than in the tables themselves. --0000000000006167110626e20055 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As far as the application being able to change those field= s itself, you can prevent that via column permissions, by leaving out the f= our audit columns and doing something like:

GRANT INSERT= (email, widget_count), UPDATE (email, widget_count) ON TABLE foobar TO PUB= LIC;

That way, inserts are guaranteed to use the d= efault=C2=A0values of current_timestamp() and current_user. And a BEFORE UP= DATE trigger ensures it changes the other two fields via the trigger functi= on only.

Cheers,
Greg

P.S. Also check out=C2=A0https:= //www.pgaudit.org/ (PGAudit) as an alternative approach, which puts the= information into your Postgres logs, rather than in the tables themselves.= =C2=A0=C2=A0
--0000000000006167110626e20055--