From: | mlw <markw(at)mohawksoft(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Hackers List <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: External search engine, advice |
Date: | 2001-05-20 21:18:16 |
Message-ID: | 3B083498.5A0220B0@mohawksoft.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>
> mlw <markw(at)mohawksoft(dot)com> writes:
> > Am I out in left field here? Does anyone see this as a problem? I guess there
> > should be three states to the lifetime of a functions return value?
>
> There has been some talk of that, but nailing down exactly what the
> semantics ought to be still needs more thought.
>
> As far as optimizing indexscans goes, the correct intermediate concept
> would be something like "result is fixed within any one scan", not any
> one transaction. You wouldn't really want to find that
>
> begin;
> select * from foo where x = functhatreadsbar();
> update bar ...;
> select * from foo where x = functhatreadsbar();
> end;
>
> does not give you the desired results.
OK, what is one to do?
There is an obvious need to use functions which return a single value, and
which can be assumed "frozen' for the life of a query or transaction, but would
absolutely break if they could never change after that. This distinction from
"iscachable" is vitally important to people coding functions for Postgres. I
know a lot of what I have written for postgres would break if the desired
meaning of "iscachable" were to be applied.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-05-20 21:25:47 | Re: Plans for solving the VACUUM problem |
Previous Message | Vadim Mikheev | 2001-05-20 21:13:37 | Re: Plans for solving the VACUUM problem |