Re: Coping with 'C' vs 'newC' function language names
От | mlw |
---|---|
Тема | Re: Coping with 'C' vs 'newC' function language names |
Дата | |
Msg-id | 3A129917.F8597510@mohawksoft.com обсуждение исходный текст |
Ответ на | AW: Coping with 'C' vs 'newC' function language names (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>) |
Ответы |
Re: Coping with 'C' vs 'newC' function language names
|
Список | pgsql-hackers |
'Marko Kreen' wrote: > > On Wed, Nov 15, 2000 at 02:42:24PM +0100, Zeugswetter Andreas SB wrote: > > > > > > We need the 7.0 style for compatibility with other DB's. Postgres was > > > > "the" pioneer in this area, but similar functionality is now available in other DB's. > > > > > > Could you explain? PostgreSQL cant be compatible in C level, why > > > the SQL compatibility? (I mean the LANGUAGE 'C' specifically) > > > > C code compatible with Informix: > > > > int32 intadd (int32 a, int32 b) > > { > > return a + b; > > } > > > > This is the same code that was standard in PostgreSQL 7.0 > > Hmm, I have not actually researched if 7.1 supports 7.0 'C' code > or not. Butthe 'newC' is anyway incompatible with 'C'. So: > > * CREATE FUNCTION .. AS 'foo.so', .. LANGUAGE 'C'; > > creates the old¬ 'C', 7.0 and ifnormix compatible funtion. > > And it is documented as deprecated, for-compatibility. > > * CREATE FUNCTION .. FROM LIBRARY 'foo.so.2' ..{name in .so} > [WITH VERSION abi_ver] > {the actual syntax needs polishing} > > creates by default the newC style fn's > but WITH VERSION 0 (e.g.) you can create the old style > functions too. > > Comments? I generally like the idea, but I am working on a text index/search project that will rely heavily on C interfacing with Postgres. I'm not sure what "NewC" is, nor do I understand what problem it is attempting to fix. -- http://www.mohawksoft.com
В списке pgsql-hackers по дате отправления: