Re: Issue in Behavior of Interval Datatype

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
Cc: "'PG Hackers'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Issue in Behavior of Interval Datatype
Date: 2012-08-04 16:11:56
Message-ID: 4694.1344096716@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Amit Kapila <amit(dot)kapila(at)huawei(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2012-08-04 16:43:04 Re: WIP pgindent replacement
Previous Message Bruce Momjian 2012-08-04 14:36:21 Re: [WIP] Performance Improvement by reducing WAL for Update Operation