Re: [HACKERS] Speedup idea: avoid using SQL procedures as aliases
От | Thomas Lockhart |
---|---|
Тема | Re: [HACKERS] Speedup idea: avoid using SQL procedures as aliases |
Дата | |
Msg-id | 36FFB842.16B4BBD1@alumni.caltech.edu обсуждение исходный текст |
Ответ на | Speedup idea: avoid using SQL procedures as aliases (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Speedup idea: avoid using SQL procedures as aliases
|
Список | pgsql-hackers |
> I noticed just now that there are a lot of SQL-language procedures in > pg_proc whose only purpose is to provide alternative names for > built-in functions. Yeah. Neat hack, eh? Edmund Mergl found this, and allowed us to use generic names for functions for the first time. But... > It strikes me that this is pretty inefficient. > I am thinking about fixing this by decoupling the user-level name of > an internal function from its C-language name. The simplest way seems > to be to modify pg_proc.h and Gen_fmgrtab.sh.in so that the C-language > name of an internal function is stored in pg_proc's "prosrc" field > (which is currently unused for internal functions) rather than being > taken from "proname". Then, all of the SQL functions that are simply > aliases for internal functions could be converted to plain internal > function entries that have proname different from prosrc. > Anyone have an objection to this? I suppose we'd need to check that > the regression tests still exercise SQL functions ;-) No objection; I've toyed with the idea of doing this, but didn't have the guts to touch the layout of system tables. You seem to have no such qualms ;) I'd be happy to help with the conversion, though I'd suggest that this would perhaps be a great topic for v6.6 since it does involve some fundamental (hopefully isolated) changes. Also, for my participation (certainly not required) I'd have more time during the next cycle... - Tom
В списке pgsql-hackers по дате отправления: