On Sun, Aug 27, 2023 at 04:14:00PM -0400, Joseph Koshakow wrote:
> On Tue, Aug 22, 2023 at 12:58 PM Jacob Champion
> wrote:
>> I wouldn't argue for backpatching, for sure, but I guess I saw this as
>> falling into the same vein as 5b3c5953 and bcc704b52 which were
>> already committed.
>
> I agre
On Tue, Aug 22, 2023 at 12:58 PM Jacob Champion
wrote:
>
> On Mon, Aug 21, 2023 at 10:39 PM Michael Paquier
wrote:
> > 0002 and 0003 make this stuff fail, but isn't there a risk that this
> > breaks applications that relied on these accidental behaviors?
> > Assuming that this is OK makes me nerv
On Mon, Aug 21, 2023 at 10:39 PM Michael Paquier wrote:
> 0002 and 0003 make this stuff fail, but isn't there a risk that this
> breaks applications that relied on these accidental behaviors?
> Assuming that this is OK makes me nervous.
I wouldn't argue for backpatching, for sure, but I guess I s
On Mon, Jul 10, 2023 at 10:42:31AM -0700, Jacob Champion wrote:
> On Mon, Jul 10, 2023 at 10:19 AM Reid Thompson
> wrote:
>> I made a another pass through the separated patches, it looks good to
>> me.
>
> LGTM too. (Thanks Tom for the clarification on ECPG.)
+SELECT INTERVAL '42 days 2 seconds
On Mon, Jul 10, 2023 at 10:19 AM Reid Thompson wrote:
> I made a another pass through the separated patches, it looks good to
> me.
LGTM too. (Thanks Tom for the clarification on ECPG.)
Marked RfC.
--Jacob
On Sun, 2023-07-09 at 13:24 -0400, Joseph Koshakow wrote:
>
> I've broken up this patch into three logical commits and attached
> them.
> None of the actual code has changed.
>
> Thanks,
> Joe Koshakow
I made a another pass through the separated patches, it looks good to
me.
Thanks,
Reid
On Sat, 2023-07-08 at 13:18 -0400, Joseph Koshakow wrote:
> Jacob Champion writes:
> > Hi Joe, here's a partial review:
>
> Thanks so much for the review!
>
> > I'm new to this code, but I agree that the use of `type` and the
> > lookahead are not particularly obvious/intuitive. At the very
> >
On Sat, Jul 8, 2023 at 5:06 PM Gurjeet Singh wrote:
> I feel the staleness/deficiencies you mention above are not
> captured in the TODO wiki page. It'd be nice if these were documented,
> so that newcomers to the community can pick up work that they feel is
> an easy lift for them.
I think that
On Sat, Jul 8, 2023 at 1:33 PM Tom Lane wrote:
>
> Gurjeet Singh writes:
> > On Fri, Jul 7, 2023 at 4:13 PM Tom Lane wrote:
> >> The ECPG datetime datatype support code has been basically unmaintained
> >> for years, and has diverged quite far at this point from the core code.
>
> > I was under
Gurjeet Singh writes:
> On Fri, Jul 7, 2023 at 4:13 PM Tom Lane wrote:
>> The ECPG datetime datatype support code has been basically unmaintained
>> for years, and has diverged quite far at this point from the core code.
> I was under the impression that anything in the postgresql.git
> reposito
On Fri, Jul 7, 2023 at 4:13 PM Tom Lane wrote:
>
> The ECPG datetime datatype support code has been basically unmaintained
> for years, and has diverged quite far at this point from the core code.
I was under the impression that anything in the postgresql.git
repository is considered core, and he
Jacob Champion writes:
> Hi Joe, here's a partial review:
Thanks so much for the review!
> I'm new to this code, but I agree that the use of `type` and the
> lookahead are not particularly obvious/intuitive. At the very least,
> they'd need some more explanation in the code. Your boolean flag id
Jacob Champion writes:
> Hi Joe, here's a partial review:
> On Sun, Apr 9, 2023 at 5:44 PM Joseph Koshakow wrote:
>> 1) Removes dead code for handling unit type RESERVE.
> Looks good. From a quick skim it looks like the ECPG copy of this code
> (ecpg/pgtypeslib/interval.c) might need to be updat
Hi Joe, here's a partial review:
On Sun, Apr 9, 2023 at 5:44 PM Joseph Koshakow wrote:
> 1) Removes dead code for handling unit type RESERVE.
Looks good. From a quick skim it looks like the ECPG copy of this code
(ecpg/pgtypeslib/interval.c) might need to be updated as well?
> 2) Restrict the u
14 matches
Mail list logo
