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 1sO4O2-00CBeJ-VP for pgsql-hackers@arkaria.postgresql.org; Sun, 30 Jun 2024 23:55:14 +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 1sO4O0-00Dx2w-03 for pgsql-hackers@arkaria.postgresql.org; Sun, 30 Jun 2024 23:55:12 +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 1sO4Nz-00Dx2o-Mr for pgsql-hackers@lists.postgresql.org; Sun, 30 Jun 2024 23:55:12 +0000 Received: from mail-lf1-x136.google.com ([2a00:1450:4864:20::136]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sO4Nw-004Nlv-7H for pgsql-hackers@postgresql.org; Sun, 30 Jun 2024 23:55:09 +0000 Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-52db11b1d31so3492523e87.0 for ; Sun, 30 Jun 2024 16:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719791706; x=1720396506; darn=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=0jh8qcuZb+TUuBqhOFvCLrHOVpMCjXkYRKqYul30X7Q=; b=jn8JbcUpA1V7WN4RyyJk37PAozL1fdsAjyAxz27D37c2NlOv8Fjmss1/m50AO9HGte XXaeTBwaBGzdJKHQFvZaY9jF7OHMuiWMRXDg6m7g+Y2dQ+PPY6AihZMfSksQWRoYykmc MpeZnw1iG5sCioThInAicdDKBROt6NpK3Qu5j7+qoupn+ymd08w8f0dF9iSpaqT5b8O9 YejZCKYTu5zuzUOTINGzvncpPtQiNnwDP2IymyMWruoXHN0Fta5EqLyAy0DkPjRVax5U Wfe0FebZZU5RifAuRa7H3D/rfX3exGzqyPlXKc+vLi6Jr96DbC16AIARM4Wvm/Z9t7aj n3FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719791706; x=1720396506; 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=0jh8qcuZb+TUuBqhOFvCLrHOVpMCjXkYRKqYul30X7Q=; b=GOPZNulf0ID3j5Mqv+OcbzGgTNwFr7Hc0hlFVLj1htgzIvSpaz+XpaameeFl6XBa/0 bdihYDDGGiE5HSGz0mhArC+7T+0Wx/HoC9rmCCLNyAvPdabwcs3Cs47Vv4ori3gRVog4 6w812MkWrg/mQ7a/vzvsICMQh8PVVEOB5h2//dT1j67KiwismRsohemvLsIt9thuidXN Ot7P7jg7MlKV94I/Nocq/6c1q/zpi86tlsurmPI1qNBYxVE3rxL/bZDcpc73lVHqd/bQ b+CA5qWz+nPvln8i7ZWp7O/vvY1N7e/Dzrs2F8epoxLrOOmswvsJMCjmllxoU8KjqN3f IVJg== X-Forwarded-Encrypted: i=1; AJvYcCWVlOz0EduONt6yRfdCE/yjfjiS4pLDOUg/xql2xMsO1oNXxdAJ9c3XQ3SJHxQ0UI84E8L8oZwo6BfPQWz6iBOhBOAZQ411g1ZZ/bm+ X-Gm-Message-State: AOJu0YzKxr9CV02yGdnnM0PkcgTkIinLDOEDorbHZbfdT9jmFU67YMcn BCWjeIGXgXkw9GJdZIvNStPK86oOZxlYAFOYlw+Wp2U+cQgFwBsiBktLbVh30id8ZGzsIVZKaPr xUc3mS3GgKeo5yU8NieDxu1rrjAo= X-Google-Smtp-Source: AGHT+IE1lsZmnCc+AhoBBphwPO/rduT6yjnwb4E+5BAe3KZchv5lNpETk11UgAJJ/hqa2TqVw0Kb7fKJuOd0xu9jrqM= X-Received: by 2002:a05:6512:2805:b0:52c:e03d:fa33 with SMTP id 2adb3069b0e04-52e827342bemr3117348e87.62.1719791705649; Sun, 30 Jun 2024 16:55:05 -0700 (PDT) MIME-Version: 1.0 References: <1362410.1719349169@sss.pgh.pa.us> <1390099.1719357084@sss.pgh.pa.us> <1642803.1719447063@sss.pgh.pa.us> In-Reply-To: From: David Rowley Date: Mon, 1 Jul 2024 11:54:50 +1200 Message-ID: Subject: Re: Should we document how column DEFAULT expressions work? To: Peter Eisentraut Cc: Tom Lane , "David G. Johnston" , James Coleman , pgsql-hackers Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, 27 Jun 2024 at 23:57, Peter Eisentraut wrote: > Maybe we should really be thinking about deprecating these special > values and steering users more urgently toward more robust alternatives. > > Imagine if 'random' were a valid input value for numeric types. I think there are valid reasons to use the special timestamp input values. One that I can think of is for use with partition pruning. If you have a time-range partitioned table and want the planner to prune the partitions rather than the executor, you could use 'now'::timestamp in your queries to allow the planner to prune. That works providing that you never use that in combination with PREPARE and never put the query with the WHERE clause inside a VIEW. I don't have any other good examples, but I suppose that if someone needed to capture the time some statement was executed and record that somewhere, sort of like the __DATE__ and __TIME__ macros in C. Perhaps that's useful to record the last time some DDL script was executed. I'd like to know what led someone down the path of doing something like DEFAULT 'now()'::timestamp in a CREATE TABLE. Could it be a faulty migration tool that created these and people copy them thinking it's a legitimate syntax? David