Thread: CREATE CAST requires immutable cast function?
It says here that CREATE CAST insists the cast function be immutable.
This seems wrong to me, in view of the fact that we have numerous
built-in casts that don't adhere to that rule --- for example,
timestamptz(date) is not immutable because it depends on the timezone
setting.
Perhaps there's a case for prohibiting volatile casts (as opposed to
stable ones), but I don't really see it. I'd prefer to just remove
this restriction. Comments?
regards, tom lane
Tom Lane wrote: > Perhaps there's a case for prohibiting volatile casts (as opposed to > stable ones), but I don't really see it. I'd prefer to just remove > this restriction. Comments? Volatile casts can blow up. I am sure that is the reasoning. ;-) -- 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 writes: > Perhaps there's a case for prohibiting volatile casts (as opposed to > stable ones), but I don't really see it. I'd prefer to just remove > this restriction. Comments? I'm not wedded to it, I just modelled it after the SQL standard, but evidently the volatility levels are different in detail. I would disallow volatile casts in any case. There ought to be a minimal behavioral contract between creators and users of types. -- Peter Eisentraut peter_e@gmx.net
Peter Eisentraut <peter_e@gmx.net> writes:
> I'm not wedded to it, I just modelled it after the SQL standard, but
> evidently the volatility levels are different in detail. I would disallow
> volatile casts in any case. There ought to be a minimal behavioral
> contract between creators and users of types.
Shrug ... ISTM the behavior of a type is whatever the type creator says
it should be. Whether a volatile cast is a good idea is dubious
(I can't think of any good examples of one offhand) but I don't see the
argument for having the system restrict the type creator's choices.
regards, tom lane