Michael Glaesemann wrote:
On Feb 18, 2007, at 20:29 , Karsten Hilbert wrote:
What I don't understand, however, is exactly *why* date_trunc is not
immutable ?
I believe it's because the result of date_trunc depends on the time zone
setting for the session.
I understand the reasoning,
On Feb 19, 2007, at 18:04 , Alban Hertroys wrote:
Michael Glaesemann wrote:
On Feb 18, 2007, at 20:29 , Karsten Hilbert wrote:
What I don't understand, however, is exactly *why* date_trunc is not
immutable ?
I believe it's because the result of date_trunc depends on the
time zone
On Feb 18, 2007, at 23:12 , Karsten Hilbert wrote:
On Sun, Feb 18, 2007 at 09:19:43PM +0900, Michael Glaesemann wrote:
What I don't understand, however, is exactly *why* date_trunc is
not immutable ?
I believe it's because the result of date_trunc depends on the time
zone setting for the
Michael Glaesemann wrote:
On Feb 19, 2007, at 18:04 , Alban Hertroys wrote:
Michael Glaesemann wrote:
On Feb 18, 2007, at 20:29 , Karsten Hilbert wrote:
What I don't understand, however, is exactly *why* date_trunc is not
immutable ?
I believe it's because the result of date_trunc
On Mon, Feb 19, 2007 at 10:16:12AM +0100, Alban Hertroys wrote:
What I'm trying to say is not that it _is_ immutable, but that it
_behaves_ immutable (under said conditions).
This could imply that if a certain condition is available in a query on
which such a function operates, it would
On Mon, Feb 19, 2007 at 10:36:36AM +0100, Karsten Hilbert wrote:
On Mon, Feb 19, 2007 at 10:16:12AM +0100, Alban Hertroys wrote:
What I'm trying to say is not that it _is_ immutable, but that it
_behaves_ immutable (under said conditions).
This could imply that if a certain condition
On Mon, Feb 19, 2007 at 10:58:50AM +0100, Martijn van Oosterhout wrote:
I'll solve it with a date_trunc_utc() wrapper.
It should be noted the date_truc(timestamptz) is not immutable, whereas
date_trunc(timestamp) is. Thus you should be able to make an index on:
date_trunc(
On Mon, Feb 19, 2007 at 12:03:07PM +0100, Karsten Hilbert wrote:
date_trunc( timestamptz_column AT TIME ZONE 'UTC', 'foo' )
Ah, that makes it clear *why* this should work.
I would assume to get meaningful results from a query using
that index I'd have to normalize input timestamps to UTC,
On Mon, Feb 19, 2007 at 12:53:15PM +0100, Martijn van Oosterhout wrote:
Well, your queries need to use the same form, ie:
SELECT blah FROM foo
WHERE date_trunc( 'entered_timestamp'::timestamptz AT TIME ZONE 'UTC', 'foo' )
Thought so.
That seems a bit error prone though, so your idea of
Alban Hertroys [EMAIL PROTECTED] writes:
What I'm trying to say is not that it _is_ immutable, but that it
_behaves_ immutable (under said conditions).
This could imply that if a certain condition is available in a query on
which such a function operates, it would behave immutable.
Right, but
On Sun, Feb 18, 2007 at 12:29:17 +0100,
Karsten Hilbert [EMAIL PROTECTED] wrote:
The date-of-birth field in our table holding patients is of
type timestamp with time zone. One of our patient search
queries uses the date-of-birth field to find matches. Since
users enter day, month, and year
On Mon, Feb 19, 2007 at 12:41:11PM -0600, Bruno Wolff III wrote:
Karsten Hilbert [EMAIL PROTECTED] wrote:
The date-of-birth field in our table holding patients is of
type timestamp with time zone. One of our patient search
queries uses the date-of-birth field to find matches. Since
On Mon, Feb 19, 2007 at 20:48:07 +0100,
Karsten Hilbert [EMAIL PROTECTED] wrote:
What time of day were you born ?
http://en.wikipedia.org/wiki/Apgar
What is the technical reason that makes you wonder ?
Because it would make doing the queries simpler.
If you aren't collecting the
On Mon, Feb 19, 2007 at 03:28:01PM -0600, Bruno Wolff III wrote:
What is the technical reason that makes you wonder ?
Because it would make doing the queries simpler.
If you aren't collecting the data, it doesn't make sense to deal with the
extra headaches involved with pretending you know
I have a question about the query optimizer of a postgres.
As long as I understood through a postgres manual, the postgres query
optimizer is implemented using a *genetic algorithm.*
I'm thinking to modify the query optimizer.
Are there any postgres version which uses typical dynamic
jungmin shin escribió:
I have a question about the query optimizer of a postgres.
As long as I understood through a postgres manual, the postgres query
optimizer is implemented using a *genetic algorithm.*
There is an algorithm said to be genetic, but it only kicks in with
big joins; 12
Hi all,
we (GNUmed) run a medical database on PostgreSQL. We are
very pleased with it (PostgreSQL, that is ;-) in all aspects.
The date-of-birth field in our table holding patients is of
type timestamp with time zone. One of our patient search
queries uses the date-of-birth field to find
followup to self:
On Sun, Feb 18, 2007 at 12:29:17PM +0100, Karsten Hilbert wrote:
So I figured it would make sense to add a functional index
on date_trunc('day', dob) to the patients table. Which
worked (appeared to, at least) with PG 7.4.
One of our users is on PG 8.2
PostgreSQL 8.1 I
On Feb 18, 2007, at 20:29 , Karsten Hilbert wrote:
What I don't understand, however, is exactly *why* date_trunc is
not immutable ?
I believe it's because the result of date_trunc depends on the time
zone setting for the session.
test=# select date_trunc('day', current_timestamp);
On Sun, Feb 18, 2007 at 09:19:43PM +0900, Michael Glaesemann wrote:
What I don't understand, however, is exactly *why* date_trunc is
not immutable ?
I believe it's because the result of date_trunc depends on the time
zone setting for the session.
...
So, given the same arguments,
Karsten Hilbert [EMAIL PROTECTED] writes:
So I figured it would make sense to add a functional index
on date_trunc('day', dob) to the patients table. Which
worked (appeared to, at least) with PG 7.4.
For the record, this was changed just before 8.0 release:
21 matches
Mail list logo
