Michael Paquier <michael.paqu...@gmail.com> writes:
> On Tue, Aug 15, 2017 at 11:37 PM, Piotr Stefaniak
> <postg...@piotr-stefaniak.me> wrote:
>> At the very least, I think timestamptz_in() should either complain about
>> being called outside of transaction or return the expected value,
>> because returning year 2000 is unuseful at best. I would also like to
>> become able to do what I'm doing in a less hacky way (assuming there
>> isn't one already but I may be wrong), perhaps once there is a new
>> 'furthest' setting for recovery_target or when recovery_target_time =
>> 'now' works as I expected.
> Hm. I think that the most simple solution here would be to change
> GetCurrentDateTime() and GetCurrentTimeUsec() so as they use
> GetCurrentTimestamp() instead of the transaction-level equivalents if
> those code paths are invoked outside of a transaction.
-1 ... every datatype I/O function is entitled to assume it's being
invoked inside a transaction. I do not think we should break that
on a case-by-case basis. So using timestamptz_in directly in xlog.c
was a bad idea, and we need to rethink that.
The semantic problem here is that if "now" is defined to mean start
of current transaction --- which it is --- then that's meaningless
outside a transaction. Redefining it as "start of current transaction,
unless we're not inside in a transaction, in which case something else"
isn't really an improvement. I think we'd be much better off throwing
an error for this case.
Not sure offhand how to mechanize that given the current code
structure. We don't want to duplicate all the infrastructure
used by timestamptz_in, certainly ... but how much of that
code is depending in some way on being inside a transaction?
I doubt that this issue with "now" is the only soft spot.
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
