From: | Hervé Piedvache <herve(at)elma(dot)fr> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Masaru Sugawara <rk73(at)echna(dot)ne(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Trouble with pg_dumpall import with 7.2 |
Date: | 2002-02-21 14:26:23 |
Message-ID: | 3C75038F.16A18969@elma.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
As always, wisdom personified by Tom Lane said :
> > regression=# create table foo (event_date_time timestamp);
> > CREATE
> > regression=# create index event_day on foo (date(event_date_time));
> > ERROR: DefineIndex: index function must be marked iscachable
> >
> > This raises a subtle point that you'd better think about before you go
> > too far in this direction: truncating a timestamp to date is not a very
> > well-defined operation, because it depends on the timezone setting.
> > Indexes on functions whose values might vary depend on who's executing
> > them are a recipe for disaster --- the index is almost certainly going
> > to wind up corrupted (out of order).
Tom, I clearly understand the problem but it is your developer's (I
should say "your designer's") POV.
Most of us, users of PG (app developers I mean) never have to deal
with timezones and that's where we conflict : we can't use (I mean as
efficiently as could be) date indexes because of timezones which WE
don't care about (at least in, say, 90% of the apps that use DB).
Can't we find a middle point ? I mean keep the current restrictions
regarding timezones but be able to create, say "noTZdate" field types
that would be cachable ?
Today we have only the options of :
- using no date index
- use inefficient date indexes
- convert dates to integers (eg: Julian) and index the integer
- convert dates to ISO strings and index the string
Same restrictions for date+time fields.
There's still something I don't understand : how are timestamps stored?
Don't you store :
1)universaltime or gmt
2)timezone ?
This way, timezones are only used to display a local date from a
universal value (which can be sorted normally)
Is it :
1)localtime
2)timezone
I guess I should RTFM or RTFS(ources)... Got a URL for dummies like me?
Oops! After re-reading my writing, I realize timezones are
important in the US though it does not change the problem.
Regards,
--
Hervé Piedvache
Elma Ingenierie Informatique
6, rue du Faubourg Saint-Honoré
F-75008 - Paris - France
http://www.elma.fr
Tel: +33-1-44949901
Fax: +33-1-44949902
Email: herve(at)elma(dot)fr
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Lockhart | 2002-02-21 14:30:37 | Re: date/time compatible problems in 7.2 |
Previous Message | Jean-Michel POURE | 2002-02-21 12:36:13 | [pgadmin-hackers] Feature request: md5sum footprint of schema objects |