From: | Keith Fiske <keith(at)omniti(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Keith <keith(at)keithf4(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, "pgsql-bugs(at)postgresql(dot)org" <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #14322: Possible inconsistent behavior with timestamp_to_str() |
Date: | 2016-09-13 20:58:01 |
Message-ID: | CAG1_KcA-RuEWO6BmmfXVGLj66ig437Cj2c8nc0UpwrhEL5PxHQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Tue, Sep 13, 2016 at 4:52 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Keith Fiske <keith(at)omniti(dot)com> writes:
> > Ok, this may be more of an actual issue than I thought. It seems that,
> even
> > if all variables to the timestamptz_to_str() function have a valid value
> > set, if it is called multiple times in the same statement, it keeps the
> > first value for all following occurrences.
>
> What is current_partition_timestamp? Is it coming from the transaction
> timestamp? That doesn't change intra-statement ...
>
> regards, tom lane
>
No, it's obtained elsewhere by querying the current max timestamp value
from the partition set.
Shouldn't matter if it was, though. You can see that all it takes to change
the string output of the timestamp is swapping the values around. The
values of the variables are the same in either case.
From | Date | Subject | |
---|---|---|---|
Next Message | Marko Tiikkaja | 2016-09-13 21:03:22 | Re: BUG #14322: Possible inconsistent behavior with timestamp_to_str() |
Previous Message | Tom Lane | 2016-09-13 20:52:22 | Re: BUG #14322: Possible inconsistent behavior with timestamp_to_str() |