From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Subject: | Re: Keeping pg_recvlogical's "feTimestamp" separate from TimestampTz |
Date: | 2017-02-18 22:18:44 |
Message-ID: | 27694.1487456324@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> I propose that what we need to do is get rid of the dangerous and
> none-too-readable-anyway use of "int64" to declare replication-protocol
> timestamps, and instead declare them as, say,
> typedef struct RPTimestamp
> {
> int64 rptimestamp;
> } RPTimestamp;
I experimented with this a bit, as in the attached draft patch, and
concluded that use of a struct is probably a bridge too far. It makes the
patch pretty invasive notationally, and yet it still fails to catch places
where nobody had bothered to even think about float timestamps anywhere
nearby; which there are several of, as per my report
https://www.postgresql.org/message-id/26788.1487455319@sss.pgh.pa.us
We might be able to salvage the parts of this that simply redeclare
appropriate variables as "IntegerTimestamp" rather than "int64", with
the type declaration just being "typedef int64 IntegerTimestamp".
If we go forward with keeping protocol fields as integer timestamps
then I'd want to do that, just so we have some notation in the code
as to what the values are meant to be. But right at the moment I'm
thinking we'd be better off to change them all to TimestampTz instead,
and adjust the arithmetic on them appropriately.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
struct-integer-timestamp.patch | text/x-diff | 46.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2017-02-18 22:26:34 | Re: pg_get_object_address() doesn't support composites |
Previous Message | Tom Lane | 2017-02-18 22:01:59 | Replication vs. float timestamps is a disaster |