From: | Grzegorz Tańczyk <goliatus(at)polzone(dot)pl> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org, polobo(at)yahoo(dot)com |
Subject: | Re: Refreshing functional index |
Date: | 2012-08-31 17:51:51 |
Message-ID: | 31666838.537771346435357900.JavaMail.root@Polzone |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hello,
W dniu 2012-08-29 23:06, Merlin Moncure pisze:
> Well, the only reason what you're trying to do works at all is because
> the database isn't stricter about double checking to see if your stuff
> is IMMUTABLE: it isn't, so of course it doesn't work. How about a
> trigger on the child table that updates an indexed column on parent?
> merlin
According to docs:
"AnIMMUTABLEfunction cannot modify the database and is guaranteed to
return the same results given the same arguments forever."
My tables look like this:
CREATE TABLE groups (
id serial PRIMARY KEY,
last_item integer REFERENCES items
) WITHOUT OIDS;
CREATE TABLE items (
id serial PRIMARY KEY,
group integer NOT NULL REFERENCES groups,
ts timestamp DEFAULT now()
) WITHOUT OIDS;
The index:
CREATE INDEX groups_last_ts
ON groups
USING btree
(items_ts(last_post));
Plpgsql function items_ts returns timestamp for given item, which will
never change(that's my assumption), so in fact according to definition
IT IS immutable fuction.
Unfortunately, whenever I update last_item column in groups, I get wrong
results, so I query like this:
SELECT * FROM groups WHERE items_ts(last_item) > now() - interval '1 week'
returns "outdated" results
I do realize about other ways for solving this problem, however I would
prefer if it worked in the way described above.
Thanks!
--
Regards,
Grzegorz
From | Date | Subject | |
---|---|---|---|
Next Message | Alan Hodgson | 2012-08-31 18:00:53 | Re: Tigger after delete with plpgsql |
Previous Message | Fellipe Henrique | 2012-08-31 17:10:47 | Tigger after delete with plpgsql |