AW: AW: Coping with 'C' vs 'newC' function language nam esh - Mailing list pgsql-hackers

From Zeugswetter Andreas SB
Subject AW: AW: Coping with 'C' vs 'newC' function language nam esh
Date
Msg-id 11C1E6749A55D411A9670001FA68796336811F@sdexcsrv1.f000.d0188.sd.spardat.at
Whole thread Raw
Responses Re: AW: AW: Coping with 'C' vs 'newC' function language nam esh
List pgsql-hackers
> > 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.

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

Andreas


pgsql-hackers by date:

Previous
From: Larry Rosenman
Date:
Subject: coding style guidelines?
Next
From: Bruce Momjian
Date:
Subject: Re: AW: AW: Coping with 'C' vs 'newC' function language nam esh