Thread: Minor point about contrib/xml2 functions "IMMUTABLE" marking
Hi, I did see the message about the change of the function signatures to include IMMUTABLE and thought "Yes, that makes sense" - however, it has now occurred to me that: 1. xpath_table uses a SELECT query to fetch the data it uses, so should presumably be marked STABLE? 2. xslt_process is to be considered IMMUTABLE if the stylesheet or document are literal values, but if either is a URL then they are fetched on evaluation. An optimisation down to one call of xslt_process (using the URL contents current at that point) almost certainly conforms with "least surprise" for most use cases, but it's not strictly true as a second call could return a different result - comments? It may be that neither of these has a significant practical impact for most users, but I thought it might be worth flagging, now that I've been working on contrib/xml2 again[*] Regards John [*] I've written an XML output function that composes the XML document structure based on the SQL join hierarchy; I'll post something on hackers for comments in the near future. This may or may not have been rendered redundant by the SQL/XML work recently added!
Agreed. I have changed them both to stable. I think xslt_process() should be stable because it is unlikely you would want a URL's contents to change inside a transaction, but likely you would want it to change between transactions. --------------------------------------------------------------------------- John Gray wrote: > Hi, > > I did see the message about the change of the function signatures to > include IMMUTABLE and thought "Yes, that makes sense" - however, it has > now occurred to me that: > > 1. xpath_table uses a SELECT query to fetch the data it uses, so should > presumably be marked STABLE? > > 2. xslt_process is to be considered IMMUTABLE if the stylesheet or > document are literal values, but if either is a URL then they are fetched > on evaluation. An optimisation down to one call of xslt_process (using the > URL contents current at that point) almost certainly conforms with "least > surprise" for most use cases, but it's not strictly true as a second call > could return a different result - comments? > > It may be that neither of these has a significant practical impact for > most users, but I thought it might be worth flagging, now that I've been > working on contrib/xml2 again[*] > > Regards > > John > > [*] I've written an XML output function that composes the XML document > structure based on the SQL join hierarchy; I'll post something on hackers > for comments in the near future. This may or may not have been rendered > redundant by the SQL/XML work recently added! > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 Index: contrib/xml2/pgxml.sql.in =================================================================== RCS file: /cvsroot/pgsql/contrib/xml2/pgxml.sql.in,v retrieving revision 1.4 diff -c -c -r1.4 pgxml.sql.in *** contrib/xml2/pgxml.sql.in 14 Jul 2005 07:12:27 -0000 1.4 --- contrib/xml2/pgxml.sql.in 13 Oct 2005 03:41:32 -0000 *************** *** 44,50 **** CREATE OR REPLACE FUNCTION xpath_table(text,text,text,text,text) RETURNS setof record AS 'MODULE_PATHNAME' ! LANGUAGE 'c' STRICT IMMUTABLE; -- XSLT functions -- Delete from here to the end of the file if you are not compiling with --- 44,50 ---- CREATE OR REPLACE FUNCTION xpath_table(text,text,text,text,text) RETURNS setof record AS 'MODULE_PATHNAME' ! LANGUAGE 'c' STRICT STABLE; -- XSLT functions -- Delete from here to the end of the file if you are not compiling with *************** *** 52,58 **** CREATE OR REPLACE FUNCTION xslt_process(text,text,text) RETURNS text ! AS 'MODULE_PATHNAME' LANGUAGE 'c' STRICT IMMUTABLE; -- the function checks for the correct argument count --- 52,58 ---- CREATE OR REPLACE FUNCTION xslt_process(text,text,text) RETURNS text ! AS 'MODULE_PATHNAME' LANGUAGE 'c' STRICT STABLE; -- the function checks for the correct argument count
On Wed, 2005-12-10 at 23:46 -0400, Bruce Momjian wrote: > Agreed. I have changed them both to stable. I think xslt_process() > should be stable because it is unlikely you would want a URL's contents > to change inside a transaction Why is it "unlikely"? If a function's return value for a particular set of arguments could change within a single table scan, the function is volatile -- ISTM xslt_process() clearly falls within that definition. -Neil
Neil Conway wrote:
> On Wed, 2005-12-10 at 23:46 -0400, Bruce Momjian wrote:
> > Agreed. I have changed them both to stable. I think xslt_process()
> > should be stable because it is unlikely you would want a URL's contents
> > to change inside a transaction
>
> Why is it "unlikely"?
>
> If a function's return value for a particular set of arguments could
> change within a single table scan, the function is volatile -- ISTM
> xslt_process() clearly falls within that definition.
My thought was that a web page lookup is going to be a very expensive
operation, so you would not want it to requery inside a transaction.
It is not like random() where you want it to be re-called and it is
inexpensive.
Our documentation says about VOLATILE:
VOLATILE indicates that the function value can change even within a single table scan, so
noopti- mizations can be made. Relatively few database functions are volatile in this
sense;some examples are random(), currval(), timeofday(). Note that any function that has
side-effectsmust be classified volatile, even if its result is quite predictable, to prevent
calls from being optimized away; an example is setval().
and I didn't think a web page lookup fit in that category.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Neil Conway wrote:
>> If a function's return value for a particular set of arguments could
>> change within a single table scan, the function is volatile -- ISTM
>> xslt_process() clearly falls within that definition.
> My thought was that a web page lookup is going to be a very expensive
> operation, so you would not want it to requery inside a transaction.
> It is not like random() where you want it to be re-called and it is
> inexpensive.
"It's too expensive" is not a valid rationale for claiming that
something is stable when it is not. In any case, you have fallen into
the all too common trap of supposing that these labels have something
to do with caching function results. Calling it stable is not going
to improve performance, only create a risk of wrong answers.
regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Well, should be marked as VOLATILE? A web lookup?
Yes. Its value is determined by factors outside the database, so
it has to be categorized as volatile.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Neil Conway wrote: > >> If a function's return value for a particular set of arguments could > >> change within a single table scan, the function is volatile -- ISTM > >> xslt_process() clearly falls within that definition. > > > My thought was that a web page lookup is going to be a very expensive > > operation, so you would not want it to requery inside a transaction. > > > It is not like random() where you want it to be re-called and it is > > inexpensive. > > "It's too expensive" is not a valid rationale for claiming that > something is stable when it is not. In any case, you have fallen into > the all too common trap of supposing that these labels have something > to do with caching function results. Calling it stable is not going > to improve performance, only create a risk of wrong answers. Well, should be marked as VOLATILE? A web lookup? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Well, should be marked as VOLATILE? A web lookup? > > Yes. Its value is determined by factors outside the database, so > it has to be categorized as volatile. OK, done. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073