Something for the TODO list: deprecating abstime and friends

On Sat, Jul 15, 2017 at 6:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Right offhand, I don't think there is any functionality in these
types that isn't handled as well or better by timestamptz, interval,
and tstzrange respectively. And they're basically undocumented
except for a sort-of deprecation notice just above section 8.5.1.
So my inclination is to remove them rather than try to upgrade them
in any way. However, we'd have to do something about:

* The legacy system views pg_shadow and pg_user have abstime columns.
Experimentation suggests that we could convert those to timestamptz(0)
and the output format wouldn't change, so maybe that's a good enough
fix there.

+1 for doing that in v11.

* contrib/spi/timetravel depends on abstime columns to represent what
would nowadays be better done as a tstzrange. I'd have thought we
could maybe toss that example module overboard, but we just today got
a question about its usage, so I'm afraid it's not quite dead yet.
What shall we do with that?

No idea. I think if nobody's willing to come up with a plan for this
and do the work to implement it, we should just remove the module when
we get closer to 2038. But I don't think we have to make that
decision for at least another 5 years or so.

While it's too late in the v10 cycle to do anything very meaningful
about this now, I am tempted to strengthen the deprecation notice's
wording from "might disappear" to "will disappear".

-1 for changing that; such predictions often turn out to be wrong.

And it's not good
that the documentation of contrib/spi/timetravel contains nothing
whatever pointing out the lack of future-proof-ness of abstime.

+1 for fixing that, though. Maybe we can find a wording that says in
effect "this module will need to be removed or fixed sometime not too
many years from now; if you care about keeping it around, maybe you
should volunteer to do the necessary fixing".

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Robert Haas <robertmhaas@gmail.com> writes:

On Sat, Jul 15, 2017 at 6:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

* contrib/spi/timetravel depends on abstime columns to represent what
would nowadays be better done as a tstzrange. I'd have thought we
could maybe toss that example module overboard, but we just today got
a question about its usage, so I'm afraid it's not quite dead yet.
What shall we do with that?

No idea. I think if nobody's willing to come up with a plan for this
and do the work to implement it, we should just remove the module when
we get closer to 2038. But I don't think we have to make that
decision for at least another 5 years or so.

The plan I'd tentatively suggest is to just s/abstime/timestamptz/g
in the timetravel module, something that would be unlikely to take more
than an hour's work. If anyone was actually using it in production
they'd have to do some ALTER COLUMN TYPE changes before the trigger
would work again ... but that would get forced on them eventually
anyway. Yup, you could turn this molehill into a mountain of work
if you wanted to have a more friendly transition, but I don't see
anyone putting in that much effort.

While it's too late in the v10 cycle to do anything very meaningful
about this now, I am tempted to strengthen the deprecation notice's
wording from "might disappear" to "will disappear".

-1 for changing that; such predictions often turn out to be wrong.

Those types will definitely fail for all use-cases in 2038, and for
many use-cases significantly before that; there's no uncertainty in that
prediction. The only way they aren't going to disappear before 2038 is
if the project is defunct first, or if somebody is sufficiently concerned
with having an easier migration path that they are willing to design and
implement one. I don't believe any of the usual suspects are going to do
that. But if there's somebody who would care enough to de-lurk and make
it happen, they'd be much more likely to do so soon enough if there's some
advance warning in the docs. Or in other words, I don't want to go from
"might disappear" in vN to gone in vN+1 with no intermediate state.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 15 July 2017 at 23:00, Tom Lane <tgl@sss.pgh.pa.us> wrote:

While it's too late in the v10 cycle to do anything very meaningful
about this now, I am tempted to strengthen the deprecation notice's
wording from "might disappear" to "will disappear".

"Will certainly disappear at some unspecified date" is a lot less
convincing than "will disappear in 2021 in Postgres 14". The specific
year and version number is irrelevant
but picking and naming a specific one makes it a lot easier to follow
through come that date.

--
greg

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Sun, Jul 16, 2017 at 1:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Or in other words, I don't want to go from
"might disappear" in vN to gone in vN+1 with no intermediate state.

I see no problem with that. First, we remove things all the time with
no deprecation warning at all when we judge that they are dead enough,
or just unsalvageable. Second, if we have said that something might
disappear and then it disappears, anyone who is unhappy about that is
being unreasonable.

In other words, I don't want to have a project policy that we will not
only put a deprecation notice on everything we remove, but it will
always be worded in a certain way. If you're trying to streamline the
process of deprecating features, that's going in the exact wrong
direction.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Sun, Jul 16, 2017 at 10:27 PM, Greg Stark <stark@mit.edu> wrote:

On 15 July 2017 at 23:00, Tom Lane <tgl@sss.pgh.pa.us> wrote:

While it's too late in the v10 cycle to do anything very meaningful
about this now, I am tempted to strengthen the deprecation notice's
wording from "might disappear" to "will disappear".

"Will certainly disappear at some unspecified date" is a lot less
convincing than "will disappear in 2021 in Postgres 14". The specific
year and version number is irrelevant
but picking and naming a specific one makes it a lot easier to follow
through come that date.

Exactly, having an exact deprecation policy would be nice. Of course
this depends on the feature we are talking about. pg_dump for example
supports servers older than what community still supports. But in most
cases, like in core data types, it would be rather safe to say that it
gets deprecated once all the versions supported by community share the
same state (remember for example 17d436d2 that was kept around for a
rather long time, or the handling of opaque function types for
triggers and PLs still present for 15 years).

Coming back to this thread... Removing abstime and reltime sounds like
the good answer to conclude this thread once the deprecation period
expires.
--
Michael

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Mon, Jul 17, 2017 at 11:37 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:

Exactly, having an exact deprecation policy would be nice. Of course
this depends on the feature we are talking about. pg_dump for example
supports servers older than what community still supports. But in most
cases, like in core data types, it would be rather safe to say that it
gets deprecated once all the versions supported by community share the
same state (remember for example 17d436d2 that was kept around for a
rather long time, or the handling of opaque function types for
triggers and PLs still present for 15 years).

Yeah, but historically it never works out. A relatively famous
example is contrib/xml2, whose documentation says:

==
From PostgreSQL 8.3 on, there is XML-related functionality based on
the SQL/XML standard in the core server. That functionality covers XML
syntax checking and XPath queries, which is what this module does, and
more, but the API is not at all compatible. It is planned that this
module will be removed in a future version of PostgreSQL in favor of
the newer standard API, so you are encouraged to try converting your
applications. If you find that some of the functionality of this
module is not available in an adequate form with the newer API, please
explain your issue to <pgsql-hackers@postgresql.org> so that the
deficiency can be addressed.
==

But until 3163baa6d2d12c28f45fec60ab313537ea9a43a4 (February 24,
2013), it said that it would be removed in PostgreSQL 8.4 (July 1,
2009), a promise that could not be fulfilled without the use of a
serviceable time machine. I proposed removing contrib/xml2 sometime
during the 8.4 or 9.0 cycle, IIRC, and got told "no". While the
updated deprecation notice is less-obviously wrong, saying that
removal is "planned" is a pretty generous assessment. It's unclear
that we've made any progress in addressing whatever the problems were
that caused the previous attempt at removal to get shot down, so it
might still be wrong: maybe xml2 is going to stick around until the
heat death of the universe.

Now, I agree that a date type which cannot represent dates after 2038
is of marginal and decreasing utility, and therefore the chances that
it will be removed are good. Probably most other people will agree as
well. But we could easily overlook the need to deliver on a promise
to remove it in a specific version, and the possibility that someone
will argue for keeping it as a matter of historical interest cannot be
ruled out. In a community where anything at all can be relitigated at
the drop of a hat, making promises about what will happen in the
future is mostly wishful thinking.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Jul 15, 2017, at 3:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

The types abstime, reltime, and tinterval need to go away, or be
reimplemented, sometime well before 2038 when they will overflow.
It's not too soon to start having a plan for that, especially seeing
that it seems to take a decade or more for us to actually get rid
of anything we've deprecated.

Right offhand, I don't think there is any functionality in these
types that isn't handled as well or better by timestamptz, interval,
and tstzrange respectively.

These types provide a 4-byte datatype for storing real-world second
precision timestamps, as occur in many log files. Forcing people to
switch to timestamp or timestamptz will incur a 4 byte per row
penalty. In my own builds, I have changed the epoch on these so
they won't wrap until sometime after 2100 C.E. I see little point in
switching to an 8-byte millisecond precision datatype when a perfectly
good 4-byte second precision datatype already serves the purpose.

That said, I am fully aware that these are deprecated and expect you
will remove them, at which time I'll have to keep them in my tree
and politely refuse to merge in your change which removes them.

mark

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Jul 17, 2017, at 12:54 PM, Mark Dilger <hornschnorter@gmail.com> wrote:

On Jul 15, 2017, at 3:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

The types abstime, reltime, and tinterval need to go away, or be
reimplemented, sometime well before 2038 when they will overflow.
It's not too soon to start having a plan for that, especially seeing
that it seems to take a decade or more for us to actually get rid
of anything we've deprecated.

Right offhand, I don't think there is any functionality in these
types that isn't handled as well or better by timestamptz, interval,
and tstzrange respectively.

These types provide a 4-byte datatype for storing real-world second
precision timestamps, as occur in many log files. Forcing people to
switch to timestamp or timestamptz will incur a 4 byte per row
penalty. In my own builds, I have changed the epoch on these so
they won't wrap until sometime after 2100 C.E. I see little point in
switching to an 8-byte millisecond precision datatype when a perfectly
good 4-byte second precision datatype already serves the purpose.

That said, I am fully aware that these are deprecated and expect you
will remove them, at which time I'll have to keep them in my tree
and politely refuse to merge in your change which removes them.

Oh, and if you could be so kind, please remove them in a commit that
does nothing else. It's much easier to skip the commit that way.

Thanks!

mark

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Mark Dilger <hornschnorter@gmail.com> writes:

On Jul 17, 2017, at 12:54 PM, Mark Dilger <hornschnorter@gmail.com> wrote:

On Jul 15, 2017, at 3:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

The types abstime, reltime, and tinterval need to go away, or be
reimplemented, sometime well before 2038 when they will overflow.

These types provide a 4-byte datatype for storing real-world second
precision timestamps, as occur in many log files. Forcing people to
switch to timestamp or timestamptz will incur a 4 byte per row
penalty. In my own builds, I have changed the epoch on these so
they won't wrap until sometime after 2100 C.E. I see little point in
switching to an 8-byte millisecond precision datatype when a perfectly
good 4-byte second precision datatype already serves the purpose.

Well, if you or somebody is willing to do the legwork, I'd be on board
with a plan that says that every 68 years we redefine the origin of
abstime. I imagine it could be done so that currently-stored abstime
values retain their present meaning as long as they're not too old.
For example the initial change would toss abstimes before 1970 overboard,
repurposing that range of values as being 2038-2106, but values between
1970 and 2038 still mean the same as they do today. If anybody still
cares in circa 2085, we toss 1970-2038 overboard and move the origin
again, lather rinse repeat.

But we're already past the point where it would be time to make the
first such switch, if we're gonna do it. So I'd like to see somebody
step up to the plate sooner not later.

I'd be inclined to toss reltime and tinterval overboard in any case.

Oh, and if you could be so kind, please remove them in a commit that
does nothing else. It's much easier to skip the commit that way.

We doubtless would do that, but you're fooling yourself if you imagine
that you can maintain such a fork for long while still tracking the
community version otherwise. Once those hand-assigned OIDs are free
they'll soon be absorbed by future feature patches, and then you'll
have enormous merge problems.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Jul 17, 2017, at 2:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Mark Dilger <hornschnorter@gmail.com> writes:

On Jul 17, 2017, at 12:54 PM, Mark Dilger <hornschnorter@gmail.com> wrote:

On Jul 15, 2017, at 3:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

The types abstime, reltime, and tinterval need to go away, or be
reimplemented, sometime well before 2038 when they will overflow.

These types provide a 4-byte datatype for storing real-world second
precision timestamps, as occur in many log files. Forcing people to
switch to timestamp or timestamptz will incur a 4 byte per row
penalty. In my own builds, I have changed the epoch on these so
they won't wrap until sometime after 2100 C.E. I see little point in
switching to an 8-byte millisecond precision datatype when a perfectly
good 4-byte second precision datatype already serves the purpose.

Well, if you or somebody is willing to do the legwork, I'd be on board
with a plan that says that every 68 years we redefine the origin of
abstime. I imagine it could be done so that currently-stored abstime
values retain their present meaning as long as they're not too old.
For example the initial change would toss abstimes before 1970 overboard,
repurposing that range of values as being 2038-2106, but values between
1970 and 2038 still mean the same as they do today. If anybody still
cares in circa 2085, we toss 1970-2038 overboard and move the origin
again, lather rinse repeat.

But we're already past the point where it would be time to make the
first such switch, if we're gonna do it. So I'd like to see somebody
step up to the plate sooner not later.

Assuming other members of the community would not object to such
a plan, I'd be willing to step up to that plate. I'll wait a respectable time,
maybe until tomorrow, to allow others to speak up.

I'd be inclined to toss reltime and tinterval overboard in any case.

Yeah, I don't use those either, preferring to cast abstime to timestamp
(or timestamptz) prior to doing any math on them.

Oh, and if you could be so kind, please remove them in a commit that
does nothing else. It's much easier to skip the commit that way.

We doubtless would do that, but you're fooling yourself if you imagine
that you can maintain such a fork for long while still tracking the
community version otherwise. Once those hand-assigned OIDs are free
they'll soon be absorbed by future feature patches, and then you'll
have enormous merge problems.

Oh, not so much. Knowing that they were going to be deprecated, I
already moved the Oids for these to something higher than 10000. In
my own builds, the Oid generator does not assign Oids lower than 65536,
which leaves room for me to assign in the 10000-65535 range without
merge headaches. It would, however, be simpler if the types did not
go away, as that would cause minor merge headaches elsewhere, such
as in the regression tests.

mark

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Mark Dilger <hornschnorter@gmail.com> writes:

On Jul 17, 2017, at 2:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Well, if you or somebody is willing to do the legwork, I'd be on board
with a plan that says that every 68 years we redefine the origin of
abstime. I imagine it could be done so that currently-stored abstime
values retain their present meaning as long as they're not too old.
For example the initial change would toss abstimes before 1970 overboard,
repurposing that range of values as being 2038-2106, but values between
1970 and 2038 still mean the same as they do today. If anybody still
cares in circa 2085, we toss 1970-2038 overboard and move the origin
again, lather rinse repeat.

Assuming other members of the community would not object to such
a plan, I'd be willing to step up to that plate.

So, thinking about how that would actually work ... the thing to do in
order to preserve existing on-disk values is to alternate between signed
and unsigned interpretations of abstimes. That is, right now, abstime
is signed with origin 1970. The conversion I'm arguing we should make
real soon now is to unsigned with origin 1970. If the project lives
so long, in circa 70 years we'd switch it to signed with origin 2106.
Yadda yadda.

Now, this should mostly work conveniently, except that we have
+/-infinity (NOEND_ABSTIME/NOSTART_ABSTIME) to deal with. Those
are nicely positioned at the ends of the signed range so that
abstime_cmp_internal() doesn't need to treat them specially.
In an unsigned world they'd be smack in the middle of the range.
We could certainly teach abstime_cmp_internal to special-case them
and deliver logically correct results, but there's a bigger problem:
those will correspond to two seconds in January 2038 that will need
to be representable when the time comes. Maybe we can make that
work by defining the values past 2038 as being two seconds less than
you might otherwise expect, but I bet it's gonna be messy. It might
be saner to just desupport +/-infinity for abstime.

The same goes for INVALID_ABSTIME, which doesn't have any clear
use-case that I know of, and is certainly not documented.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Jul 17, 2017, at 3:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Mark Dilger <hornschnorter@gmail.com> writes:

On Jul 17, 2017, at 2:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Well, if you or somebody is willing to do the legwork, I'd be on board
with a plan that says that every 68 years we redefine the origin of
abstime. I imagine it could be done so that currently-stored abstime
values retain their present meaning as long as they're not too old.
For example the initial change would toss abstimes before 1970 overboard,
repurposing that range of values as being 2038-2106, but values between
1970 and 2038 still mean the same as they do today. If anybody still
cares in circa 2085, we toss 1970-2038 overboard and move the origin
again, lather rinse repeat.

Assuming other members of the community would not object to such
a plan, I'd be willing to step up to that plate.

So, thinking about how that would actually work ... the thing to do in
order to preserve existing on-disk values is to alternate between signed
and unsigned interpretations of abstimes. That is, right now, abstime
is signed with origin 1970. The conversion I'm arguing we should make
real soon now is to unsigned with origin 1970. If the project lives
so long, in circa 70 years we'd switch it to signed with origin 2106.
Yadda yadda.

Right, I already had the same idea. That's not how I am doing it in my
fork currently, but that's what you would want to do to support any values
already stored somewhere.

Now, this should mostly work conveniently, except that we have
+/-infinity (NOEND_ABSTIME/NOSTART_ABSTIME) to deal with. Those
are nicely positioned at the ends of the signed range so that
abstime_cmp_internal() doesn't need to treat them specially.
In an unsigned world they'd be smack in the middle of the range.
We could certainly teach abstime_cmp_internal to special-case them
and deliver logically correct results, but there's a bigger problem:
those will correspond to two seconds in January 2038 that will need
to be representable when the time comes. Maybe we can make that
work by defining the values past 2038 as being two seconds less than
you might otherwise expect, but I bet it's gonna be messy. It might
be saner to just desupport +/-infinity for abstime.

I don't use those values, so it is no matter to me if we desupport them. It
seems a bit pointless, though, because we still have to handle legacy
values that we encounter. I assume some folks will have those values in
their tables when they upgrade.

The same goes for INVALID_ABSTIME, which doesn't have any clear
use-case that I know of, and is certainly not documented.

Likewise, I don't know how to desupport this while still supporting legacy
tables.

mark

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Mark Dilger <hornschnorter@gmail.com> writes:

On Jul 17, 2017, at 3:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Now, this should mostly work conveniently, except that we have
+/-infinity (NOEND_ABSTIME/NOSTART_ABSTIME) to deal with ... It might
be saner to just desupport +/-infinity for abstime.

I don't use those values, so it is no matter to me if we desupport them. It
seems a bit pointless, though, because we still have to handle legacy
values that we encounter. I assume some folks will have those values in
their tables when they upgrade.

Well, some folks will also have pre-1970 dates in their tables, no?
We're just blowing those off. They'll print out as some post-2038
date or other, and too bad.

Basically, the direction this is going in is that abstime will become
an officially supported type, but its range of supported values is "not
too many decades either way from now". If you are using it to store
very old dates then You're Doing It Wrong, and eventually you'll get
bitten. Given that contract, I don't see a place for +/-infinity.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Jul 17, 2017, at 3:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Mark Dilger <hornschnorter@gmail.com> writes:

On Jul 17, 2017, at 3:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Now, this should mostly work conveniently, except that we have
+/-infinity (NOEND_ABSTIME/NOSTART_ABSTIME) to deal with ... It might
be saner to just desupport +/-infinity for abstime.

I don't use those values, so it is no matter to me if we desupport them. It
seems a bit pointless, though, because we still have to handle legacy
values that we encounter. I assume some folks will have those values in
their tables when they upgrade.

Well, some folks will also have pre-1970 dates in their tables, no?
We're just blowing those off. They'll print out as some post-2038
date or other, and too bad.

Basically, the direction this is going in is that abstime will become
an officially supported type, but its range of supported values is "not
too many decades either way from now". If you are using it to store
very old dates then You're Doing It Wrong, and eventually you'll get
bitten. Given that contract, I don't see a place for +/-infinity.

Works for me.

mark

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Jul 17, 2017, at 3:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Mark Dilger <hornschnorter@gmail.com> writes:

On Jul 17, 2017, at 2:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Well, if you or somebody is willing to do the legwork, I'd be on board
with a plan that says that every 68 years we redefine the origin of
abstime. I imagine it could be done so that currently-stored abstime
values retain their present meaning as long as they're not too old.
For example the initial change would toss abstimes before 1970 overboard,
repurposing that range of values as being 2038-2106, but values between
1970 and 2038 still mean the same as they do today. If anybody still
cares in circa 2085, we toss 1970-2038 overboard and move the origin
again, lather rinse repeat.

Assuming other members of the community would not object to such
a plan, I'd be willing to step up to that plate.

So, thinking about how that would actually work ... the thing to do in
order to preserve existing on-disk values is to alternate between signed
and unsigned interpretations of abstimes. That is, right now, abstime
is signed with origin 1970. The conversion I'm arguing we should make
real soon now is to unsigned with origin 1970. If the project lives
so long, in circa 70 years we'd switch it to signed with origin 2106.
Yadda yadda.

Now, this should mostly work conveniently, except that we have
+/-infinity (NOEND_ABSTIME/NOSTART_ABSTIME) to deal with. Those
are nicely positioned at the ends of the signed range so that
abstime_cmp_internal() doesn't need to treat them specially.
In an unsigned world they'd be smack in the middle of the range.
We could certainly teach abstime_cmp_internal to special-case them
and deliver logically correct results, but there's a bigger problem:
those will correspond to two seconds in January 2038 that will need
to be representable when the time comes. Maybe we can make that
work by defining the values past 2038 as being two seconds less than
you might otherwise expect, but I bet it's gonna be messy. It might
be saner to just desupport +/-infinity for abstime.

The same goes for INVALID_ABSTIME, which doesn't have any clear
use-case that I know of, and is certainly not documented.

I use the abstime type in some catalog tables, and if I allowed those
fields to have something equivalent to NULL, which I do not, I would need
INVALID_ABSTIME, since NULL is not allowed in the constant header of a
catalog table.

I wonder if old versions of postgres had catalog tables with abstime used
in this way? Other than that, I can't think of a reason to use INVALID_ABSTIME.

mark

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Jul 17, 2017, at 2:34 PM, Mark Dilger <hornschnorter@gmail.com> wrote:

On Jul 17, 2017, at 2:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Mark Dilger <hornschnorter@gmail.com> writes:

On Jul 17, 2017, at 12:54 PM, Mark Dilger <hornschnorter@gmail.com> wrote:

On Jul 15, 2017, at 3:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

The types abstime, reltime, and tinterval need to go away, or be
reimplemented, sometime well before 2038 when they will overflow.

These types provide a 4-byte datatype for storing real-world second
precision timestamps, as occur in many log files. Forcing people to
switch to timestamp or timestamptz will incur a 4 byte per row
penalty. In my own builds, I have changed the epoch on these so
they won't wrap until sometime after 2100 C.E. I see little point in
switching to an 8-byte millisecond precision datatype when a perfectly
good 4-byte second precision datatype already serves the purpose.

Well, if you or somebody is willing to do the legwork, I'd be on board
with a plan that says that every 68 years we redefine the origin of
abstime. I imagine it could be done so that currently-stored abstime
values retain their present meaning as long as they're not too old.
For example the initial change would toss abstimes before 1970 overboard,
repurposing that range of values as being 2038-2106, but values between
1970 and 2038 still mean the same as they do today. If anybody still
cares in circa 2085, we toss 1970-2038 overboard and move the origin
again, lather rinse repeat.

But we're already past the point where it would be time to make the
first such switch, if we're gonna do it. So I'd like to see somebody
step up to the plate sooner not later.

Assuming other members of the community would not object to such
a plan, I'd be willing to step up to that plate. I'll wait a respectable time,
maybe until tomorrow, to allow others to speak up.

There was not much conversation about this, so I went ahead with what
I think makes a logical first step. The attached patch removes the tinterval
datatype from the sources.

I intend to remove reltime next, and then make the changes to abstime in
a third patch.

mark

On Jul 18, 2017, at 9:13 PM, Mark Dilger <hornschnorter@gmail.com> wrote:

On Jul 17, 2017, at 2:34 PM, Mark Dilger <hornschnorter@gmail.com> wrote:

On Jul 17, 2017, at 2:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Mark Dilger <hornschnorter@gmail.com> writes:

On Jul 17, 2017, at 12:54 PM, Mark Dilger <hornschnorter@gmail.com> wrote:

On Jul 15, 2017, at 3:00 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

The types abstime, reltime, and tinterval need to go away, or be
reimplemented, sometime well before 2038 when they will overflow.

These types provide a 4-byte datatype for storing real-world second
precision timestamps, as occur in many log files. Forcing people to
switch to timestamp or timestamptz will incur a 4 byte per row
penalty. In my own builds, I have changed the epoch on these so
they won't wrap until sometime after 2100 C.E. I see little point in
switching to an 8-byte millisecond precision datatype when a perfectly
good 4-byte second precision datatype already serves the purpose.

Well, if you or somebody is willing to do the legwork, I'd be on board
with a plan that says that every 68 years we redefine the origin of
abstime. I imagine it could be done so that currently-stored abstime
values retain their present meaning as long as they're not too old.
For example the initial change would toss abstimes before 1970 overboard,
repurposing that range of values as being 2038-2106, but values between
1970 and 2038 still mean the same as they do today. If anybody still
cares in circa 2085, we toss 1970-2038 overboard and move the origin
again, lather rinse repeat.

But we're already past the point where it would be time to make the
first such switch, if we're gonna do it. So I'd like to see somebody
step up to the plate sooner not later.

Assuming other members of the community would not object to such
a plan, I'd be willing to step up to that plate. I'll wait a respectable time,
maybe until tomorrow, to allow others to speak up.

There was not much conversation about this, so I went ahead with what
I think makes a logical first step. The attached patch removes the tinterval
datatype from the sources.

I intend to remove reltime next, and then make the changes to abstime in
a third patch.

As predicted, this second patch (which should be applied *after* the prior
tinterval_abatement patch) removes the reltime datatype from the sources.

mark

Mark Dilger <hornschnorter@gmail.com> writes:

On Jul 18, 2017, at 9:13 PM, Mark Dilger <hornschnorter@gmail.com> wrote:
There was not much conversation about this, so I went ahead with what
I think makes a logical first step. The attached patch removes the tinterval
datatype from the sources.

As predicted, this second patch (which should be applied *after* the prior
tinterval_abatement patch) removes the reltime datatype from the sources.

Seems like a good plan. Please be sure to add these patches to the next
commitfest, so we remember them when the time comes.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Mon, Jul 17, 2017 at 6:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

So, thinking about how that would actually work ... the thing to do in
order to preserve existing on-disk values is to alternate between signed
and unsigned interpretations of abstimes. That is, right now, abstime
is signed with origin 1970. The conversion I'm arguing we should make
real soon now is to unsigned with origin 1970. If the project lives
so long, in circa 70 years we'd switch it to signed with origin 2106.
Yadda yadda.

Doesn't this plan amount to breaking pg_upgrade compatibility and
hoping that nobody notice? Existing values will be silently
reinterpreted according to the new rules. If we had two actually
separate types and let people convert columns from the old type to the
new type with just a validation scan, that would be engineering at the
level of quality that I've come to associate with this project. If
this type is so marginal that we don't want to do that kind of work,
then I think we should just rip it out; that doesn't preclude someone
maintaining it in their own fork, or even adding it back as a new type
in a contrib module with a #define for the base year. Silently
changing the interpretation of the same data in the core code, though,
seems both far too clever and not clever enough.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers