Re: Issue in Behavior of Interval Datatype - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Issue in Behavior of Interval Datatype
Date
Msg-id 4694.1344096716@sss.pgh.pa.us
Whole thread Raw
In response to Re: Issue in Behavior of Interval Datatype  (Amit Kapila <amit.kapila@huawei.com>)
Responses Re: Issue in Behavior of Interval Datatype
List pgsql-hackers
Amit Kapila <amit.kapila@huawei.com> writes:
> Yes, this is right that tmask need not be changed, also one more thing I
> have noticed that
> in file Interval.c also there is a function DecodeInterval() which is
> currently little different
> from DecodeInterval() in datetime.c for DTK_TZ case.
> For example Assert check is commented.
> Why the Assert check is commented out there?    

Assert doesn't work in client-side code.

More generally, nobody is maintaining ecpg's copy of the datetime code,
and that's been true for a very long time.  I'm not personally
interested in trying to re-sync that copy.  It would be more useful to
figure out a way to get rid of it.  There have been past discussions of
how we could make a single copy of the code work in both backend and
frontend contexts, but the frontend environment is so impoverished by
comparison (no Assert, no elog, no palloc) that it hasn't looked like an
attractive idea.  It's also fairly unclear whether anyone is actually
using ecpg's client-side datetime support, which means there's little
motivation to put a lot of work into it.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [WIP] Performance Improvement by reducing WAL for Update Operation
Next
From: Bruce Momjian
Date:
Subject: Re: WIP pgindent replacement