Re: string_to_array has to be stable? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: string_to_array has to be stable?
Date
Msg-id 27031.1280422813@sss.pgh.pa.us
Whole thread Raw
In response to Re: string_to_array has to be stable?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: string_to_array has to be stable?
List pgsql-hackers
I wrote:
> BTW, the situation on the input side is a bit different: record_in is
> volatile because domain_in is, and I think we'd better leave that alone
> since it's not too hard to believe that a domain might have volatile
> CHECK expressions.  If we had arrays of domains, anyarray_in would have
> to be volatile too, but we don't and it isn't.

Oh, wait: we have arrays of composites now, and a composite could
contain a domain.  So that's wrong too; anyarray_in had better be marked
volatile.  In general it seems that the coding rules need to be:

* if you depend on an arbitrary type output function, assume it's stable.

* if you depend on an arbitrary type input function, assume it's volatile.

* similarly for binary send/receive functions.

Or we could decide that volatile domain CHECK expressions are un-sensible
and just relabel all these input functions as stable, which would make
everything consistent.  Thoughts?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: string_to_array has to be stable?
Next
From: Robert Haas
Date:
Subject: Re: reducing NUMERIC size for 9.1