Thread: Minor point about contrib/xml2 functions "IMMUTABLE" marking

Minor point about contrib/xml2 functions "IMMUTABLE" marking

From
John Gray
Date:
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!


Re: Minor point about contrib/xml2 functions "IMMUTABLE" marking

From
Bruce Momjian
Date:
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


Re: Minor point about contrib/xml2 functions "IMMUTABLE"

From
Neil Conway
Date:
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




Re: Minor point about contrib/xml2 functions "IMMUTABLE" marking

From
Bruce Momjian
Date:
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
 


Re: Minor point about contrib/xml2 functions "IMMUTABLE" marking

From
Tom Lane
Date:
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


Re: Minor point about contrib/xml2 functions "IMMUTABLE" marking

From
Tom Lane
Date:
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


Re: Minor point about contrib/xml2 functions "IMMUTABLE" marking

From
Bruce Momjian
Date:
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
 


Re: Minor point about contrib/xml2 functions "IMMUTABLE" marking

From
Bruce Momjian
Date:
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