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

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: John Gray <jgray(at)azuli(dot)co(dot)uk>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Minor point about contrib/xml2 functions "IMMUTABLE" marking
Date: 2005-10-13 03:46:31
Message-ID: 200510130346.j9D3kVA11440@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Attachment Content-Type Size
unknown_filename text/plain 1.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-10-13 03:49:47 Re: [COMMITTERS] pgsql: Do all accesses to shared buffer headers through
Previous Message Neil Conway 2005-10-13 03:28:27 Re: [COMMITTERS] pgsql: Do all accesses to shared buffer