Обсуждение: Re: [INTERFACES] Updated IDL with considerations for COSS

"Taral" <taral@cyberjunkie.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

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

Use of _ is discouraged since in the IDL-to-C mapping _ replaces ::. However
we can do:

module PostgreSQL { // Note we already separate our namespace
  module Types {
    typedef short int2;
    typedef short int4;
    // etc.
  }

// Stuff

}

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

No, you're quite right... I did most of my study of the CORBA 2.2 spec at
1am... IDL modified.

Taral

P.S. Would it be possible to make a pgsql/src/corba module and let me check
this IDL file into it? That way I don't have to keep reposting it.

On Mon, 16 Nov 1998, Taral wrote:

> P.S. Would it be possible to make a pgsql/src/corba module and let me check
> this IDL file into it? That way I don't have to keep reposting it.

Send me a patch of what you want, and tell me wher eyou want it, and I'll
add it to the repository...

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org