inserting records with $dowork in Postgres
Gary Giumarra
ggiumarra at yahoo.com
Fri Aug 17 20:14:27 EDT 2018
Well, unless I don’t understand you correctly, I think you have it backwards:
now() - keeps it the same for all inserts and updates in a given transaction
clock_timestamp - the timestamp value changes for each insert or update in the transaction or function (it will be the value of the server’s clock as each insert or update occurs)
Gary Giumarra
ggiumarra at yahoo.com
661.301.3204 (voice + text)
> On Aug 17, 2018, at 9:36 AM, Doug Easterbrook <doug at artsman.com> wrote:
>
> hi Gary,
>
> you are right… we tend to use now() since we want the date in the insert to change within the transaction, if inserting multiple records within the transaction or if its in a function.
>
> clock_timestamp — keeps it the same in the transaction.
>
>
>
> as a side note for others reading this — these are all values at server time — and they include timezone. For what its worth, all our dates in postgres are set to timestamp WITH timezone so that all our database are now timezone aware. that plus, one other command makes it easy to make a timezone aware application in omnis.
>
>
>
> its just so cool when you can get the database to be smart and do stuff for you. Omnis + Postgres = a potent solution
>
>
>
>
>
> Doug Easterbrook
> Arts Management Systems Ltd.
> mailto:doug at artsman.com
> http://www.artsman.com
> Phone (403) 650-1978
>
>> On Aug 17, 2018, at 7:48 AM, Gary Giumarra via omnisdev-en <omnisdev-en at lists.omnis-dev.com> wrote:
>>
>>
>> Depending on what you want to capture you may want to use clock_timestamp() instead of now(). In my experience usually now() - aka transaction_timestamp() - is what you will want but just be advised that every row in a given transaction that takes the value of now() either as part of an insert or an update will have exactly the same timestamp value, whereas with clock_timestamp() they will have the time the given insert or update occurred (which, unless it's a long transaction, should be almost, but not exactly the same, unless they occur within the precision of the timestamp column). Just to make it more complicated there is also statement_timestamp(), but I'm betting you won't need that.
>> If you're really interested: https://www.postgresql.org/docs/current/static/functions-datetime.html#FUNCTIONS-DATETIME-CURRENT
>>
>> Gary Giumarra
>>
>> ggiumarra at yahoo.com
>> mobile + text 661.301.3204
>
More information about the omnisdev-en
mailing list