On 02/25/2016 01:58 AM, Karsten Hilbert wrote:
On Wed, Feb 24, 2016 at 04:12:22PM -0800, Adrian Klaver wrote:
This works fine, the application (GNUmed) ensures INSERTS and
UPDATES do the right thing with .is_ongoing and .ts_end.
Now the following sequence happens:
- insert row with .is_ongoin
On Wed, Feb 24, 2016 at 05:24:44PM -0700, David G. Johnston wrote:
> Then you must record the "INSERT/UPDATE time" into the table, as a
> constant, and refer to that value instead of having "now()" which happens
> to be correct at the time of the insert/update but is not correct at any
> future p
On Wed, Feb 24, 2016 at 04:12:22PM -0800, Adrian Klaver wrote:
> >This works fine, the application (GNUmed) ensures INSERTS and
> >UPDATES do the right thing with .is_ongoing and .ts_end.
> >
> >Now the following sequence happens:
> >
> >- insert row with .is_ongoing=true and .ts_end=tomorrow()
>
On Wed, Feb 24, 2016 at 3:12 PM, Karsten Hilbert
wrote:
> I have noticed another problem during pg_upgrade on a 9.1
> cluster with 9.4 as the target.
>
> Consider this sort of table
>
> create table therapy (
> pk serial primary key,
> description text,
>
On 02/24/2016 02:12 PM, Karsten Hilbert wrote:
I have noticed another problem during pg_upgrade on a 9.1
cluster with 9.4 as the target.
Consider this sort of table
create table therapy (
pk serial primary key,
description text,
is_ongoing
