Feedback-ID: ie0a040ee:Fastmail
Message-ID: <bff385a9-adba-4516-8164-a1239f2f002a@eisentraut.org>
Date: Mon, 1 Jul 2024 16:26:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Should we document how column DEFAULT expressions work?
To: David Rowley <dgrowleyml@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
 "David G. Johnston" <david.g.johnston@gmail.com>,
 James Coleman <jtc331@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
References: <CAAaqYe-wQPbchCUE7pocPNEQ3PMY8a98Txmxc7q0+FvXtk1vvg@mail.gmail.com>
 <1362410.1719349169@sss.pgh.pa.us>
 <CAAaqYe9_RE2WximHuYRpyfU-H2G+W--49e_8GDqS-vHLOzPvmg@mail.gmail.com>
 <1390099.1719357084@sss.pgh.pa.us>
 <CAKFQuwZkgm0yqHhf05thqu1gzUK__gXBL5tyBuFvKoOe7Dd6=A@mail.gmail.com>
 <CAApHDvoiHYxM2VQYZeiF7JAdP7Y0JxEr86NZpUjoZ9AA4cpzYw@mail.gmail.com>
 <CAKFQuwbyjn0p5aKz1sKfJHQCTbGy1xhWaNR2xdnXv-X4oPdOGA@mail.gmail.com>
 <CAApHDvqShXhOat03iEV1VqXM68DBJ+zM95Ghbu0rcqs8KnhQQQ@mail.gmail.com>
 <1642803.1719447063@sss.pgh.pa.us>
 <CAApHDvouPRyga3-5ZYLt_RUhU942bk0WPVgro+U=R3cvBRXbeQ@mail.gmail.com>
 <ef4d9b38-b7a5-4c85-ba12-062929c2d136@eisentraut.org>
 <CAApHDvrURTcDn3GTsmXzm9VqT3acLh=T=aUYMuKrtozw0nq8Tg@mail.gmail.com>
Content-Language: en-US
From: Peter Eisentraut <peter@eisentraut.org>
In-Reply-To: <CAApHDvrURTcDn3GTsmXzm9VqT3acLh=T=aUYMuKrtozw0nq8Tg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/bff385a9-adba-4516-8164-a1239f2f002a%40eisentraut.org>
Precedence: bulk

On 01.07.24 01:54, David Rowley wrote:
> On Thu, 27 Jun 2024 at 23:57, Peter Eisentraut <peter@eisentraut.org> 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.

Yeah, but is that a good user interface?  Or is that just something that 
happens to work now with the pieces that happened to be there, rather 
than a really designed interface?

Hypothetically, what would need to be done to make this work with now() 
or current_timestamp or something similar?  Do we need a new stability 
level that somehow encompasses this behavior, so that the function call 
can be evaluated at planning time?

> That
> works providing that you never use that in combination with PREPARE
> and never put the query with the WHERE clause inside a VIEW.

And this kind of thing obviously makes this interface even worse.