pg.ddx.io  pgsql-sql@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Cc: Andrew Sullivan <andrew@libertyrms.info>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [SQL] [GENERAL] CURRENT_TIMESTAMP
Date: Thu, 03 Oct 2002 19:09:33 -0400
Message-ID: <15244.1033686573@sss.pgh.pa.us> (raw)
In-Reply-To: <200210032215.g93MFx823428@candle.pha.pa.us>
References: <200210032215.g93MFx823428@candle.pha.pa.us>

Bruce Momjian <pgman@candle.pha.pa.us> writes:
> So, in summary, reasons for the change:
> 	more intuitive
> 	more standard-compliant
> 	more closely matches other db's

I'd give you the first and third of those.  As Andrew noted, the
argument that "it's more standard-compliant" is not very solid.

> Reasons not to change:
> 	PostgreSQL traditional behavior

You've phrased that in a way that makes it sound like the decision
is a no-brainer.  How about

	Breaks existing Postgres applications in non-obvious ways

which I think is a more realistic description of the downside.

Also, it seems a lot of people who have thought about this carefully
think that the start-of-transaction behavior is just plain more useful.
The fact that it surprises novices is not a reason why people who know
the behavior shouldn't want it to work like it does.  (The behavior of
nextval/currval for sequences surprises novices, too, but I haven't
heard anyone claim we should change it because of that.)

So I think a fairer summary is

Pro:

	more intuitive (but still not what an unversed person would
			expect, namely true current time)
	arguably more standard-compliant
	more closely matches other db's (but still not very closely)

Con:

	breaks existing Postgres applications in non-obvious ways
	arguably less useful than our traditional behavior

I've got no problem with the idea of adding a way to get at
statement-arrival time.  (I like the idea of a parameterized version of
now() to provide a consistent interface to all three functionalities.)
But I'm less than enthused about changing the existing functions to give
pride of place to statement-arrival time.  In the end, I think that
transaction-start time is the most commonly useful and safest variant,
and so I feel it ought to have pride of place as the easiest one to get
at.

			regards, tom lane



view thread (61+ messages)  latest in thread

Message-ID: <15244.1033686573@sss.pgh.pa.us>
Permalink:  ../15244.1033686573@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/15244.1033686573@sss.pgh.pa.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-sql@postgresql.org
  Cc: tgl@sss.pgh.pa.us, pgman@candle.pha.pa.us, andrew@libertyrms.info, pgsql-hackers@postgresql.org
  Subject: Re: [SQL] [GENERAL] CURRENT_TIMESTAMP
  In-Reply-To: <15244.1033686573@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox