
> > 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)

C code compatible with Informix:

int32 intadd (int32 a, int32 b)
{
	return a + b;
}

This is the same code that was standard in PostgreSQL 7.0

Andreas

Wed, 15 Nov 2000 14:42:24 +0100
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
AW: Coping with 'C' vs 'newC' function language names
On Wed, Nov 15, 2000 at 02:42:24PM +0100, Zeugswetter Andreas SB wrote:
> 
> > > 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)
> 
> C code compatible with Informix:
> 
> int32 intadd (int32 a, int32 b)
> {
> 	return a + b;
> }
> 
> This is the same code that was standard in PostgreSQL 7.0

Hmm, I have not actually researched if 7.1 supports 7.0 'C' code
or not.  Butthe 'newC' is anyway incompatible with 'C'. So:

* CREATE FUNCTION .. AS 'foo.so', .. LANGUAGE 'C';

  creates the oldï¿½ 'C', 7.0 and ifnormix compatible funtion.

  And it is documented as deprecated, for-compatibility.

* CREATE FUNCTION .. FROM LIBRARY 'foo.so.2' ..{name in .so}
  [WITH VERSION abi_ver]
     {the actual syntax needs polishing}

  creates by default the newC style fn's
  but WITH VERSION 0 (e.g.) you can create the old style
  functions too.

Comments?

-- 
marko


Wed, 15 Nov 2000 16:03:26 +0200
"'Marko Kreen'" <marko@l-t.ee>
Re: Coping with 'C' vs 'newC' function language names
'Marko Kreen' wrote:
> 
> On Wed, Nov 15, 2000 at 02:42:24PM +0100, Zeugswetter Andreas SB wrote:
> >
> > > > 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)
> >
> > C code compatible with Informix:
> >
> > int32 intadd (int32 a, int32 b)
> > {
> >       return a + b;
> > }
> >
> > This is the same code that was standard in PostgreSQL 7.0
> 
> Hmm, I have not actually researched if 7.1 supports 7.0 'C' code
> or not.  Butthe 'newC' is anyway incompatible with 'C'. So:
> 
> * CREATE FUNCTION .. AS 'foo.so', .. LANGUAGE 'C';
> 
>   creates the oldï¿½ 'C', 7.0 and ifnormix compatible funtion.
> 
>   And it is documented as deprecated, for-compatibility.
> 
> * CREATE FUNCTION .. FROM LIBRARY 'foo.so.2' ..{name in .so}
>   [WITH VERSION abi_ver]
>      {the actual syntax needs polishing}
> 
>   creates by default the newC style fn's
>   but WITH VERSION 0 (e.g.) you can create the old style
>   functions too.
> 
> Comments?

I generally like the idea, but I am working on a text index/search
project that will rely heavily on C interfacing with Postgres.

I'm not sure what "NewC" is, nor do I understand what problem it is
attempting to fix.


-- 
http://www.mohawksoft.com

Wed, 15 Nov 2000 09:09:27 -0500
mlw <markw@mohawksoft.com>
Re: Coping with 'C' vs 'newC' function language names
mlw <markw@mohawksoft.com> writes:
> I'm not sure what "NewC" is, nor do I understand what problem it is
> attempting to fix.

I haven't gotten around to updating the main documentation yet (my bad)
but the design document about the fmgr rewrite is in current sources
as src/backend/utils/fmgr/README --- you can read it on the web at
http://www.postgresql.org/cgi/cvsweb.cgi/pgsql/src/backend/utils/fmgr/README
if you don't have a local copy.

The key issues are summarized in that document as:

: We know that the existing mechanism for calling Postgres functions needs
: to be redesigned.  It has portability problems because it makes
: assumptions about parameter passing that violate ANSI C; it fails to
: handle NULL arguments and results cleanly; and "function handlers" that
: support a class of functions (such as fmgr_pl) can only be done via a
: really ugly, non-reentrant kluge.  (Global variable set during every
: function call, forsooth.)  Here is a proposal for fixing these problems.

To answer another misconception that I saw in this thread:

: The old language names "internal" and "C" will continue to refer to
: functions with the old calling convention.  We should deprecate
: old-style functions because of their portability problems, but the
: support for them will only be one small function handler routine,
: so we can leave them in place for as long as necessary.

			regards, tom lane

Wed, 15 Nov 2000 11:13:39 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: Coping with 'C' vs 'newC' function language names 
> To answer another misconception that I saw in this thread:
> 
> : The old language names "internal" and "C" will continue to refer to
> : functions with the old calling convention.  We should deprecate
> : old-style functions because of their portability problems, but the
> : support for them will only be one small function handler routine,
> : so we can leave them in place for as long as necessary.

My question is can we drop newC and use just plain C in 7.2 or 7.3?

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

Wed, 15 Nov 2000 23:42:05 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: Coping with 'C' vs 'newC' function language namesh
At 23:42 15/11/00 -0500, Bruce Momjian wrote:
>> To answer another misconception that I saw in this thread:
>> 
>> : The old language names "internal" and "C" will continue to refer to
>> : functions with the old calling convention.  We should deprecate
>> : old-style functions because of their portability problems, but the
>> : support for them will only be one small function handler routine,
>> : so we can leave them in place for as long as necessary.
>
>My question is can we drop newC and use just plain C in 7.2 or 7.3?

I plan to work on a a proposal for a (hopefully) version independant
function manager interface; the idea behind the proposal is to allow PGSQL
to query the modules for information about the functions, but calling a
single known entry point. The information stored in the database relation
would be substantially reduced, and the backends would load the module then
enquire about the functions, storing the results in memory. The kind of SQL
required would be:

    Create Function foo(int4, int4) from library 'path-to-lib';

and possibly,

    Create Module foo_mod from library 'path-to-lib';

The idea being to only store whe function signature and enough details to
get to the info-function. If 'Create Module' were allowed, then it would
automatically create appropriate function definitions when the statement
was executed.

The info-function would return data in a struct passed from the backend,
and part of the struct would include version information. The backend would
then be responsible for handling new & old protocols.


----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|
                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/

Thu, 16 Nov 2000 16:16:26 +1100
Philip Warner <pjw@rhyme.com.au>
Re: Coping with 'C' vs 'newC' function language
  namesh
On Thu, Nov 16, 2000 at 04:16:26PM +1100, Philip Warner wrote:
> 
> and possibly,
> 
>     Create Module foo_mod from library 'path-to-lib';
> 
> The idea being to only store whe function signature and enough details to
> get to the info-function. If 'Create Module' were allowed, then it would
> automatically create appropriate function definitions when the statement
> was executed.
> 

Phil - be careful with the nomenclature. We've got another naming collision,
here. SQL9[29] talk about modules, which may or may not be related to what
your suggesting here.

Ross
-- 
Open source code is like a natural resource, it's the result of providing
food and sunshine to programmers, and then staying out of their way.
[...] [It] is not going away because it has utility for both the developers 
and users independent of economic motivations.  Jim Flynn, Sunnyvale, Calif.

Thu, 16 Nov 2000 09:32:43 -0600
"Ross J. Reedstrom" <reedstrm@rice.edu>
Re: Coping with 'C' vs 'newC' function language namesh
On Thu, Nov 16, 2000 at 09:32:43AM -0600, Ross J. Reedstrom wrote:
> On Thu, Nov 16, 2000 at 04:16:26PM +1100, Philip Warner wrote:
> >     Create Module foo_mod from library 'path-to-lib';
> 
> Phil - be careful with the nomenclature. We've got another naming collision,
> here. SQL9[29] talk about modules, which may or may not be related to what
> your suggesting here.

Do you know any url's where the SQL* standards could be looked
up?

Mark Hollomon's idea was to use 'package' not 'module', but
ofcourse it would be nice to be SQL* conforming.

-- 
marko


Thu, 16 Nov 2000 17:51:07 +0200
"'Marko Kreen'" <marko@l-t.ee>
Re: Coping with 'C' vs 'newC' function language namesh
At 05:51 PM 11/16/00 +0200, 'Marko Kreen' wrote:
>On Thu, Nov 16, 2000 at 09:32:43AM -0600, Ross J. Reedstrom wrote:
>> On Thu, Nov 16, 2000 at 04:16:26PM +1100, Philip Warner wrote:
>> >     Create Module foo_mod from library 'path-to-lib';
>> 
>> Phil - be careful with the nomenclature. We've got another naming
collision,
>> here. SQL9[29] talk about modules, which may or may not be related to what
>> your suggesting here.
>
>Do you know any url's where the SQL* standards could be looked
>up?

I have a copy of the SQL92 draft (the one that's circulated among this
group in
the past) at dsl-dhogaza.pacifier.net.  Just use anonymous ftp, it's in the
pub
directory with an obvious name (sql1992.txt???)



- Don Baccus, Portland OR <dhogaza@pacifier.com>
  Nature photos, on-line guides, Pacific Northwest
  Rare Bird Alert Service and other goodies at
  http://donb.photo.net.

Thu, 16 Nov 2000 07:53:41 -0800
Don Baccus <dhogaza@pacifier.com>
Re: Coping with 'C' vs 'newC' function language
  namesh
On Thu, Nov 16, 2000 at 05:51:07PM +0200, 'Marko Kreen' wrote:
> On Thu, Nov 16, 2000 at 09:32:43AM -0600, Ross J. Reedstrom wrote:
> > On Thu, Nov 16, 2000 at 04:16:26PM +1100, Philip Warner wrote:
> > >     Create Module foo_mod from library 'path-to-lib';
> > 
> > Phil - be careful with the nomenclature. We've got another naming collision,
> > here. SQL9[29] talk about modules, which may or may not be related to what
> > your suggesting here.
> 
> Do you know any url's where the SQL* standards could be looked
> up?
> 
> Mark Hollomon's idea was to use 'package' not 'module', but
> ofcourse it would be nice to be SQL* conforming.

Well, the 1999 standards seem to live at:

ftp://jerry.ece.umassd.edu/isowg3/x3h2/Standards/

Which is the working repository for the ANSI database committee (x3h2)

Ross
-- 
Open source code is like a natural resource, it's the result of providing
food and sunshine to programmers, and then staying out of their way.
[...] [It] is not going away because it has utility for both the developers 
and users independent of economic motivations.  Jim Flynn, Sunnyvale, Calif.

Thu, 16 Nov 2000 09:59:26 -0600
"Ross J. Reedstrom" <reedstrm@rice.edu>
Re: Coping with 'C' vs 'newC' function language namesh