Re: [HACKERS] Modules
От | Thomas G. Lockhart |
---|---|
Тема | Re: [HACKERS] Modules |
Дата | |
Msg-id | 351F3C91.D6F79352@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] Data type removal (dg@illustra.com (David Gould)) |
Список | pgsql-hackers |
> All this would be done by the init function in the module you load. > What we need is a set of functions callable by modules, like > module_register_type(name, descr, func*, textin*, textout*, whatever > ...) > module_register_smgr(name, descr, .....) > module_register_command(.... > Casts would be done by converting to a common format (text) and then to > the desired type. Use textin/textout. No special cast functions would > have to exist. Why doesn't it work this way already??? Would not that > solve all casting problems? It does work this way already, at least in some cases. It definitely does not solve casting problems, for several reasons, two of which are: - textout->textin is inefficient compared to binary conversions. - type conversion also may require value and format manipulation far beyond what you would accept for an input function for a specific type. That is, to convert a type to another type may require a conversion which would not be acceptable in any case other than a conversion from that specific type to the target type. You need to call a specialized routine to do this. > Dependencies are checked by the OS kernel when you try to unload > modules. You cannot unload slhc without first unloading ppp, for > example. What's the difference? Granularity. If, for example, we had a package of 6 types and 250 functions, you would need to check each of these for dependencies. David was just pointing out that it isn't as easy, not that it is impossible. I thought his list of issues was fairly complete, and any solution would address these somehow... - Tom
В списке pgsql-hackers по дате отправления: