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@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026