Re: Coping with 'C' vs 'newC' function language names
От | Marko Kreen |
---|---|
Тема | Re: Coping with 'C' vs 'newC' function language names |
Дата | |
Msg-id | 20001115152201.A4600@l-t.ee обсуждение исходный текст |
Ответ на | AW: Coping with 'C' vs 'newC' function language names (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>) |
Список | pgsql-hackers |
On Mon, Nov 13, 2000 at 09:58:30AM +0100, Zeugswetter Andreas SB wrote: > > > > because as said, it can be any other language besides C and also > > > the 'AS file' is weird. > > > > This is interesting. It allows us to control the default behavour of > > "C". I would vote to default to 7.0-style when no version is used for > > 7.1, then default to 7.1 style in 7.2 and later. We don't need > > backward C function compatibility for more than one release, I think. > > 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) I see already three different C interfaces: 1) 7.0.x 2) 7.1.x 3) > 7.1 where is possible to give a generic funtion/struct where the backend can guess the actual params, also with some docstrings, etc... Per-function interface needs not to change. How do you see it possible to solve with current LANGUAGE 'fooC' approach? -- marko
В списке pgsql-hackers по дате отправления: