Andrew Dunstan wrote:
> Florian G. Pflug wrote:
>>
>> I think you're overly pessimistic here ;-) This classification can be done
>> quite efficiently as long as your language is "static enough". The trick is
>> not to execute the function, but to scan the code to find all other
>> functions and SQL statements a given function may possibly call. If your
>> function calls no SQL statements, and only other functions already marked
>> IMMUTABLE, then it must be IMMUTABLE itself.
>>
>> It does seem that only pl/pgsql is "static enough" for this to work,
>> though, making this idea rather unappealing.
>>
>
> How would you propose to analyse C functions, for which you might not have
> the C code?
Scanning the binary, together with symbol annotations for immutability of course
;-))
No, seriously. I do *not* advocate that we actually autoclassify functions, for
a lot of reasons. I just wanted to refute the statement that doing so is
generally impossible - it's not. It's trivial for some languages (In haskhell
for example all functions that don't use monads are immutable, and their
signature tell if they do use monads or or), realistic for others (pl/pgsql,
where we do have the sourcecode), and utterly impossible for others
(pl/{ruby,python,perl,...}, pl/c, ...).
Besides - AFAICS *anything* that makes VACUUM depend on IMMUTABLE to be correct
would instantly break tsearch, no? At least as long as we allow changing
stopwords and the like of dictionaries used by an index - which we'd better
allow, unless we want the DBAs to come with pitchforks after us...
regards, Florian Pflug, who shudders when imagining DBAs with pitchforks...
