From: | Matt Kelly <mkellycs(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Exposing the stats snapshot timestamp to SQL |
Date: | 2015-01-30 04:35:38 |
Message-ID: | CA+KcUkiR+54mX1528tTAZx4PeCeqrYax7gdv3ANL1y1hfKT6Ww@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 29, 2015 at 8:42 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Matt Kelly <mkellycs(at)gmail(dot)com> writes:
> > Jim, I'm not sure I understand what you mean? This new function follows
> > the same conventions as everything else in the file. TimestampTz is
> just a
> > typedef for int64.
>
> ... or double. Have you checked that the code behaves properly with
> --disable-integer-timestamps?
>
> regards, tom lane
>
Well, yes int or double. I should have been more clear about that. Its a
good point though that I should run the server with disable for
completeness.
I presume you meant --disable-integer-datetimes. I just ran that test case
now, all set.
For my own edification, was there really any risk of something so trivial
breaking due to that setting, or was it just for completeness? (which is a
perfectly valid reason)
Thanks,
- Matt K.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-01-30 05:07:22 | Re: Exposing the stats snapshot timestamp to SQL |
Previous Message | Michael Paquier | 2015-01-30 04:07:09 | Re: Safe memory allocation functions |