public inbox for [email protected]
help / color / mirror / Atom feedFrom: Peter Eisentraut <[email protected]>
To: David Rowley <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: David G. Johnston <[email protected]>
Cc: James Coleman <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: Should we document how column DEFAULT expressions work?
Date: Mon, 1 Jul 2024 16:26:22 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAApHDvrURTcDn3GTsmXzm9VqT3acLh=T=aUYMuKrtozw0nq8Tg@mail.gmail.com>
References: <CAAaqYe-wQPbchCUE7pocPNEQ3PMY8a98Txmxc7q0+FvXtk1vvg@mail.gmail.com>
<[email protected]>
<CAAaqYe9_RE2WximHuYRpyfU-H2G+W--49e_8GDqS-vHLOzPvmg@mail.gmail.com>
<[email protected]>
<CAKFQuwZkgm0yqHhf05thqu1gzUK__gXBL5tyBuFvKoOe7Dd6=A@mail.gmail.com>
<CAApHDvoiHYxM2VQYZeiF7JAdP7Y0JxEr86NZpUjoZ9AA4cpzYw@mail.gmail.com>
<CAKFQuwbyjn0p5aKz1sKfJHQCTbGy1xhWaNR2xdnXv-X4oPdOGA@mail.gmail.com>
<CAApHDvqShXhOat03iEV1VqXM68DBJ+zM95Ghbu0rcqs8KnhQQQ@mail.gmail.com>
<[email protected]>
<CAApHDvouPRyga3-5ZYLt_RUhU942bk0WPVgro+U=R3cvBRXbeQ@mail.gmail.com>
<[email protected]>
<CAApHDvrURTcDn3GTsmXzm9VqT3acLh=T=aUYMuKrtozw0nq8Tg@mail.gmail.com>
On 01.07.24 01:54, David Rowley wrote:
> On Thu, 27 Jun 2024 at 23:57, Peter Eisentraut <[email protected]> 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.
view thread (17+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Should we document how column DEFAULT expressions work?
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox