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

[ Charset ISO-8859-1 unsupported, converting... ]
>
> > > 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.

But we have very few Informix functions moving to PostgreSQL.

>
> 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".

My concern is that this is confusing. All our documentation says the
style is called C. Functions are confusing enough. Adding a new name
for our default function type could add to the confusion.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026