AW: AW: Coping with 'C' vs 'newC' function language nam esh

Поиск
Список
Период
Сортировка
От Zeugswetter Andreas SB
Тема AW: AW: Coping with 'C' vs 'newC' function language nam esh
Дата
Msg-id 11C1E6749A55D411A9670001FA68796336811F@sdexcsrv1.f000.d0188.sd.spardat.at
обсуждение исходный текст
Ответы Re: AW: AW: Coping with 'C' vs 'newC' function language nam esh  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
> > 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).
> 
> My problem with newC is that I think it is going to cause confusing by
> people who create new-style functions and call the language "C".  I
> recommend making our current code "C" style, and calling pre-7.1
> functions "C70", that way, we can still enable old functions to work,
> they just have to use "C70" to make them work, and all our new code is
> the clean "C" type.

This would be ok if the "newC" would be like any one other implementation,
but it is not. It is a PostgreSQL specific fmgr interface.

Our old "C" fmgr interface is more or less exactly the same as in Informix
(no wonder, they copied Illustra). In Informix this fmgr interface is called "C",
that is why I would like to keep the "old" style "C" also. 
It is something with a sort of pseudo standard character.

For the new interface, something that makes clear that it is PostgreSQL specific
would imho be good, like "pgC". 
Or see my previous mail about "parameter style postgresql".

Andreas


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Larry Rosenman
Дата:
Сообщение: coding style guidelines?
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: AW: AW: Coping with 'C' vs 'newC' function language nam esh