On 2/22/17 7:56 AM, Andres Freund wrote:
On 2017-02-22 08:43:28 -0500, Tom Lane wrote:
Andres Freund <and...@anarazel.de> writes:
On 2017-02-22 00:10:35 -0600, Jim Nasby wrote:
I wounder if a separate "floatstamp" data type might fit the bill there. It
might not be completely seamless, but it would be binary compatible.
I don't really see what'd that solve.
Seems to me this is a different name for what I already tried in
<27694.1487456...@sss.pgh.pa.us>.  It would be much better than doing
nothing, IMO, but it would still leave lots of opportunities for mistakes.
It sounded more like Jim suggested a full blown SQL type, given that he
replied to my concern about the possible need for a deprecation period
due to pg_upgrade concerns.  To be useful for that, we'd need a good
chunk of magic, so all existing uses of timestamp[tz] are replaced with
floattimestamp[tz], duplicate some code, add implicit casts, and accept
that composites/arrays won't be fixed.  That sounds like a fair amount
of work to me, and we'd still have no way to remove the code without
causing pain.

Right, but I was thinking more in line with just providing the type (as an extension, perhaps not even in core) and making it possible for pg_upgrade to switch fields over to that type. That would allow an in-place upgrade of a really large cluster. A user would still need to modify their code to use the new type.

Put another way: add ability for pg_upgrade to change the type of a field. There might be other uses for that as well.
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532)

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

Reply via email to