Rick Hillegas <[EMAIL PROTECTED]> writes: > Mike Matrigali wrote: >> Rick Hillegas wrote: >>> Thanks, Mike. I don't think I understand what the upgrade issues >>> are. Could you explain? >>> >>> Regards, >>> -Rick >>> >> I may just have jumped in too soon, as I don't really understand >> what the encoding that was a problem is actually doing. I was just >> working off the info in the bug and saw the word's encoding which >> felt like something that was going to encode something that went to >> disk and then would be read from >> disk later on subsequent database boots. Anything like that would >> seem like it might present problems if we have to change the >> encoding in a new version of the software - so it would be easier to >> get it "right" now rather than have multiple versions of it. >> >> Maybe you could explain what is being encoded and if it is actually ever >> making it to disk. From description I was assuming it was in some >> catalog that held the info about the table function. > Thanks for digging into this issue, Mike. What's being serialized (and > encoded) is the signature of a Table Function. This serialized form is > kept in the in-memory query plan and retrieved from memory when the > Table Function is instantiated. I don't believe that these plans are > ever stored on disk. If they were, I agree that we would want to sand > this down now.
I think we store the compiled plans on disk if they are used in triggers. Could we call the table functions from triggers? Anyway, I think this only means that we can't change the format on the 10.4 branch. Stored prepared statements are invalidated when we upgrade the database to a higher minor version, so we won't see any problems if the format is changed on trunk. -- Knut Anders
