Re: Trouble with pg_dumpall import with 7.2

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

In response to

Responses

Browse pgsql-hackers by date

  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