Re: [INTERFACES] Updated IDL with considerations for COSS
От | Michael Robinson |
---|---|
Тема | Re: [INTERFACES] Updated IDL with considerations for COSS |
Дата | |
Msg-id | 199811161531.XAA09964@public.bta.net.cn обсуждение исходный текст |
Ответы |
RE: [INTERFACES] Updated IDL with considerations for COSS
|
Список | pgsql-interfaces |
"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
В списке pgsql-interfaces по дате отправления: