On Thu, Jul 29, 2010 at 1:00 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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?
Aren't volatile CHECK expressions pretty un-sensible in general? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
