Re: [INTERFACES] Updated IDL with considerations for COSS

From: Michael Robinson <robinson(at)public(dot)bta(dot)net(dot)cn>
To: pgsql-interfaces(at)hub(dot)org, taral(at)cyberjunkie(dot)com
Subject: Re: [INTERFACES] Updated IDL with considerations for COSS
Date: 1998-11-16 15:31:03
Message-ID: 199811161531.XAA09964@public.bta.net.cn
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

"Taral" <taral(at)cyberjunkie(dot)com> writes:
>module PostgreSQL {

In the interest of maximum interoperability, I'd suggest finding what is
the predominant deployed CORBA database interface (or interfaces), factoring
out the commonalities, differences, and incompatibilities with what we want
to do with PostgreSQL, and see if we can benefit from interface inheritance
(single or multiple).

> // Standard types
> typedef short int2type;
> typedef long int4type;

In the future, we will want to implement an Interface Repository to map
the PostgreSQL type tables to CORBA IDL. Since that involves an indeterminate
number of user-defined types, I recommend carving out namespace for that
purpose at the beginning, e.g.:

typedef short pgtype_int2;
typedef long pgtype_int4;

> struct int8type {
> long lsw;
> long msw;
> };

I would recommend that fixed-length PostgreSQL types be defined as little-
endian arrays of long or octet type, whichever is appropriate. E.g.:

typedef long pgtype_int8[2];
typedef long pgtype_int28[4];
typedef octet pgtype_macaddr[6];
typedef octet pgtype_filename[256];

Etc. It's more orthogonal that way. But again, if prevailing practice is
something else, we should look closely at that. Sign extension of multi-
long integral types is another problem that someone has presumably already
solved for us.

-Michael Robinson

Responses

Browse pgsql-interfaces by date

  From Date Subject
Next Message Taral 1998-11-16 15:32:36 RE: [INTERFACES] ORB API
Previous Message Taral 1998-11-16 15:29:46 RE: [INTERFACES] ORB API