pg.ddx.io  pgsql-interfaces@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Hannu Krosing <hannu@trust.ee>
To: pgsql-interfaces@hub.org
Cc: Michael Robinson <robinson@public.bta.net.cn>
Cc: maillist@candle.pha.pa.us
Cc: scrappy@hub.org
Cc: tgl@sss.pgh.pa.us
Subject: Re: [HACKERS] More PostgreSQL+CORBA
Date: Sun, 15 Nov 1998 16:06:23 +0200
Message-ID: <364EDFDF.A08EE918@trust.ee> (raw)
References: <199811150424.MAA28899@public.bta.net.cn>

Ok, moved to interfaces as suggested

Maybe it would be a good idea to strip CC:s ?

Michael Robinson wrote:
> 
> 
> >       As for 6-9 months...I think this is more in Michael court then
> >anything...I don't see why work can't start on it now, even if its nothing
> >more then Michael submitting patches that have the relevant sections
> >#ifdef's so that they are only enabled for those working on it.  I don't
> >imagine this is going to be a "now it isn't, now it is" sort of thing...it
> >might take 6-9 months to implement...
> 
> This is my plan:
>         1. Wrap the current libpq API in CORBA, as a proof of concept

Add 1.A. here: extend current FE<->BE interface to support prepared 
statements, at least to the level of SPI, maybe even _start_ from
"extended" 
SPI CORBA interface. "Extended" because SPI had same deficiences as 
well compared to the "main" FE<->BE protocol.

>         2. Implement a static row-level interface, which maps PostgreSQL
>            types to CORBA types

2.A. Define a standard way for CORBA'fying the postgresql 
user-defined types

>         3. Design a fully dynamic interface, complete with Interface
>            Repository integration with the PostgreSQL type system
>         4. Implement the design
>
> Number one shouldn't take very long (a few weeks, once I get the whole
> CORBA development thing sorted out).  Two shouldn't take much longer.
> Three and four is anybody's guess, and, as I mentioned earlier, four
> depends on currently unimplemented sections of ORBit.

I think, that we should start with an ORB that has C-interface 
'cause the rest of PostgreSQL is in C. 

The time will probably be better spent on implementing the 
unimplemented sections rather than writing a C to C++ wrapper 
(the part which should in theory be made unneccesary by CORBA !)

So supporting other language IDL mappings
(C++,java,python,ada,smalltalk,...) 
directly in backend seems not to be a very good idea

Of course we should support all C mappings.

------------------
Hannu



view thread (43+ messages)  latest in thread

Message-ID: <364EDFDF.A08EE918@trust.ee>
Permalink:  ../364EDFDF.A08EE918@trust.ee/
Also on:    postgresql.org/message-id/364EDFDF.A08EE918@trust.ee

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-interfaces@postgresql.org
  Cc: hannu@trust.ee, pgsql-interfaces@hub.org, robinson@public.bta.net.cn, maillist@candle.pha.pa.us, scrappy@hub.org, tgl@sss.pgh.pa.us
  Subject: Re: [HACKERS] More PostgreSQL+CORBA
  In-Reply-To: <364EDFDF.A08EE918@trust.ee>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox