On Wed, Nov 09, 2005 at 10:57:25AM -0500, Tom Lane wrote: > There are cases where it would work, and other cases where it wouldn't. > Given the pain involved in debugging when it's wrong, maybe we should > just endeavor to forbid loading of all wrong-version modules. > > I'm not sure that there's any real easy way to detect this though. > For V1-style functions we could embed a version number in the > per-function info structs, but that doesn't help for old-style > functions.
Given the lack of information you get for old style I'm not sure we should care. do a lot of people use it still? I think that if we're going to expand the Pg_finfo_record struct, I think it could also include (optionally): - A length field (for future upwardly compatable changes). - Allow the specification of flags like strict and volatile so the coder doesn't have to worry about getting the SQL install script right. - Indication of number of parameters/datatypes - A description for pg_proc Ofcourse, then you're getting into the realm of [1]. Still, at least flags like STRICT would be useful because then the source code can assert that it can/cannot accept NULLs, so users can't screw it up. [1] http://archives.postgresql.org/pgsql-hackers/2005-09/msg00476.php -- Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
pgpf8LUpvWMyg.pgp
Description: PGP signature
