AW: Coping with 'C' vs 'newC' function language namesh
От | Zeugswetter Andreas SB |
---|---|
Тема | AW: Coping with 'C' vs 'newC' function language namesh |
Дата | |
Msg-id | 11C1E6749A55D411A9670001FA687963368118@sdexcsrv1.f000.d0188.sd.spardat.at обсуждение исходный текст |
Ответы |
Re: AW: Coping with 'C' vs 'newC' function language namesh
|
Список | pgsql-hackers |
> > To answer another misconception that I saw in this thread: > > > > : The old language names "internal" and "C" will continue to refer to > > : functions with the old calling convention. We should deprecate > > : old-style functions because of their portability problems, but the > > : support for them will only be one small function handler routine, > > : so we can leave them in place for as long as necessary. > > My question is can we drop newC and use just plain C in 7.2 or 7.3? Has anybody had time to look at how this is done in DB/2, Oracle ? Philip ? In Informix there is an additional keyword "parameter style". Thus you have: create function foo (a int, b int) return{s|ing} int external name '/path/libmod.so(symbol)' language C [parameter style informix] [not variant]; We could have "parameter style postgresql" and map that to some arbitrary string that would not be something the user sees. As you see this is really very close to what we have or want and I am really unhappy that there has been no effort at all to look at what others do. Not that we want to copy some stupidity, but if it is sane .... These are also the companies that have the most influence on future ANSI specs, and thus if we keep close we will have a better position to stay conformant. Actually my proposal would be to not advertise "newC" in 7.1 and do some more research in that area until we have a solid and maybe compatible interface that also makes the missing features possible (multiple columns and rows for return, enter the function more than once to retrieve only part of the result if it consists of many rows). Andreas
В списке pgsql-hackers по дате отправления: