From: | Marko Kreen <marko(at)l-t(dot)ee> |
---|---|
To: | Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'Bruce Momjian'" <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Coping with 'C' vs 'newC' function language names |
Date: | 2000-11-15 13:22:02 |
Message-ID: | 20001115152201.A4600@l-t.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Zeugswetter Andreas SB | 2000-11-15 13:42:24 | AW: Coping with 'C' vs 'newC' function language names |
Previous Message | Martin A. Marques | 2000-11-15 12:14:18 | Re: PHPBuilder article -- Postgres vs MySQL |