From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | "Eric B(dot) Ridge" <ebr(at)tcdi(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org, Brandon Craig Rhodes <brandon(at)oit(dot)gatech(dot)edu> |
Subject: | Re: key = currval('tab_key_seq') choses SEQSCAN?! |
Date: | 2004-02-26 04:20:34 |
Message-ID: | 403D7412.8090509@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Eric B. Ridge wrote:
> gotcha. Stated differently, it's not volatile because, by design, it
> doesn't always produce the same output for the same input.
Right. But further, it doesn't even produce the same result within a
single scan. Here's from pg_proc.h:
/*
* Symbolic values for provolatile column: these indicate whether the
* result of a function is dependent *only* on the values of its
* explicit arguments, or can change due to outside factors (such as
* parameter variables or table contents). NOTE: functions having
* side-effects, such as setval(), must be labeled volatile to ensure
* they will not get optimized away, even if the actual return value is
* not changeable.
*/
#define PROVOLATILE_IMMUTABLE 'i' /* never changes for given input */
#define PROVOLATILE_STABLE 's' /* does not change within a scan */
#define PROVOLATILE_VOLATILE 'v' /* can change even within a scan */
> OT: generate_series looks useful. Is this only in 7.5?
Yes, new in 7.5.
Joe
From | Date | Subject | |
---|---|---|---|
Next Message | Tiptur, Sathish (MED) | 2004-02-26 07:35:03 | postgreSQL licenseing |
Previous Message | Shelby Cain | 2004-02-26 04:18:59 | Re: select statement against pg_stats returns inconsistent data |