On Tue, Feb 26, 2019 at 02:29:01PM +, Simon Riggs wrote:
> Looks good, would need docs.
The ALTER TABLE page just says "old type is either binary coercible to the new
type or an unconstrained domain over the new type." Avoiding rewrites by way
of a prosupport function or the at-timestamp-v2.p
Noah Misch writes:
> On Tue, Feb 26, 2019 at 10:46:29AM -0500, Tom Lane wrote:
>> It'd be nice to get the SupportRequestSimplify API correct from the first
>> release, so if there's even a slightly plausible reason for it to support
>> this, I'd be inclined to err in the direction of doing so.
>
On Tue, Feb 26, 2019 at 10:46:29AM -0500, Tom Lane wrote:
> Noah Misch writes:
> > Stepping back a bit, commit b8a18ad didn't provide a great UI. I doubt
> > folks
> > write queries this way spontaneously; to do so, they would have needed to
> > learn that such syntax enables this optimization.
Noah Misch writes:
> Stepping back a bit, commit b8a18ad didn't provide a great UI. I doubt folks
> write queries this way spontaneously; to do so, they would have needed to
> learn that such syntax enables this optimization. If I'm going to do
> something more invasive, it should optimize the i
On Tue, 26 Feb 2019 at 06:14, Noah Misch wrote:
> On Thu, Feb 05, 2015 at 08:36:18PM -0500, Noah Misch wrote:
> > On Tue, Nov 05, 2013 at 05:02:58PM -0800, Josh Berkus wrote:
> > > I'd also love some way of doing a no-rewrite conversion between
> > > timestamp and timestamptz, based on the assump
On Thu, Feb 05, 2015 at 08:36:18PM -0500, Noah Misch wrote:
> On Tue, Nov 05, 2013 at 05:02:58PM -0800, Josh Berkus wrote:
> > I'd also love some way of doing a no-rewrite conversion between
> > timestamp and timestamptz, based on the assumption that the original
> > values are UTC time. That's on
