Thread: timestamp refactor effort

timestamp refactor effort

From
"Warren Turkal"
Date:
So...in the vein of my last mail, I have tried to create another patch
for refactoring out some of the HAVE_INT64_TIMESTAMP ifdefs in the
code in timestamp.c. I have attached the patch. Please let me know if
this patch is acceptable and what I can do to continue this effort.

Thanks,
wt

Attachment

Re: timestamp refactor effort

From
Tom Lane
Date:
"Warren Turkal" <wturkal@gmail.com> writes:
> So...in the vein of my last mail, I have tried to create another patch
> for refactoring out some of the HAVE_INT64_TIMESTAMP ifdefs in the
> code in timestamp.c. I have attached the patch. Please let me know if
> this patch is acceptable and what I can do to continue this effort.

Hmm, PackedTime seems like a fairly random name for the type --- there's
not anything particularly "packed" about it IMO.

I'm a bit inclined to suggest just using the Timestamp typedef.
I guess though that there's some risk of confusion between values
that actually are "timestamp without time zone" and values that need
the same representation but aren't actually intended to represent a
specific point in time.

Maybe "TimeOffset" or "TimeValue" or something like that?

Other than the name game, I think you're headed in the right direction.
        regards, tom lane


Re: timestamp refactor effort

From
"Warren Turkal"
Date:
On Jan 12, 2008 5:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Hmm, PackedTime seems like a fairly random name for the type --- there's
> not anything particularly "packed" about it IMO.
>
> I'm a bit inclined to suggest just using the Timestamp typedef.
> I guess though that there's some risk of confusion between values
> that actually are "timestamp without time zone" and values that need
> the same representation but aren't actually intended to represent a
> specific point in time.
>
> Maybe "TimeOffset" or "TimeValue" or something like that?

I do agree that Timestamp seems to express the same thing PackedTime
does Should we rename Timestamp to TimeOffset?

> Other than the name game, I think you're headed in the right direction.

Thanks.

I have a question. Are the low level representations of Timestamp and
TimestampTZ the same?

wt


Re: timestamp refactor effort

From
"Warren Turkal"
Date:
-my gmail account

On Jan 13, 2008 12:13 AM, Warren Turkal <turkal@google.com> wrote:
> On Jan 12, 2008 5:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Hmm, PackedTime seems like a fairly random name for the type --- there's
> > not anything particularly "packed" about it IMO.
> >
> > I'm a bit inclined to suggest just using the Timestamp typedef.
> > I guess though that there's some risk of confusion between values
> > that actually are "timestamp without time zone" and values that need
> > the same representation but aren't actually intended to represent a
> > specific point in time.
> >
> > Maybe "TimeOffset" or "TimeValue" or something like that?
>
> I do agree that Timestamp seems to express the same thing PackedTime
> does Should we rename Timestamp to TimeOffset?
>
> > Other than the name game, I think you're headed in the right direction.
>
>
> Thanks.
>
> I have a question. Are the low level representations of Timestamp and
> TimestampTZ the same?
>
> wt
>


Re: timestamp refactor effort

From
Tom Lane
Date:
"Warren Turkal" <turkal@google.com> writes:
> I have a question. Are the low level representations of Timestamp and
> TimestampTZ the same?

They're the same but the interpretations are different, which is why
I think it's useful to have two typedefs as a way of documenting what
any given value is intended to be.  The argument for having a third
typedef would be exactly the same: to help document what a value is
intended to be.
        regards, tom lane


Re: timestamp refactor effort

From
"Warren Turkal"
Date:
On Jan 13, 2008 9:21 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Warren Turkal" <turkal@google.com> writes:
> > I have a question. Are the low level representations of Timestamp and
> > TimestampTZ the same?
>
> They're the same but the interpretations are different, which is why
> I think it's useful to have two typedefs as a way of documenting what
> any given value is intended to be.  The argument for having a third
> typedef would be exactly the same: to help document what a value is
> intended to be.

Makes sense.

wt