Thread: AW: Coping with 'C' vs 'newC' function language names
> > 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
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
'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
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
> 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, Pennsylvania19026
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 |/
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.
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
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 Serviceand other goodies at http://donb.photo.net.
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.