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, Pennsylvania 19026