pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedUpdated IDL with considerations for COSS
5+ messages / 3 participants
[nested] [flat]
* Updated IDL with considerations for COSS
@ 1998-11-16 03:33 Taral <taral@cyberjunkie.com>
0 siblings, 0 replies; 5+ messages in thread
From: Taral @ 1998-11-16 03:33 UTC (permalink / raw)
To: pgsql-interfaces@hub.org
Took a look at COSS and modified this to be upgradable...
Taral
P.S. Back to one file... MICO doesn't care about any support/no any support
:) We can always use #ifdef/#ifndef
--- cut here ---
module PostgreSQL {
// Standard types
typedef short int2type;
typedef long int4type;
struct int8type {
long lsw;
long msw;
};
// Direct row interface
//
// *** This interface is critical!
// *** It will be used in the final COSS Query Service compliant
implementation.
//
// Allows read-write access to a row without issuing a slow UPDATE
// Will throw an object-does-not-exist (??) exception if the row gets
deleted
interface Row {
typedef sequence<Cell> type;
attribute type data; // set operation not yet implemented
void delete();
};
// <info>
// More about the application of COSS:
//
// A Table will be a QueryableCollection of Rows
// A Database will be a QueryableCollection of Tables
// Both will be queryable via the Query Service
//
// Relations will be representable using the Relationship Service
// This includes primary/foreign keys and anything else :)
//
// GRANT/REVOKE can be supplied via the Security Service
//
// See a pattern here? The whole of SQL can be implemented by these
services!
// The statements go through a parser. Queries and subqueries are passed
to the
// database for processing. Returned items are handled appropriately:
//
// SELECT: return the items to the caller
// UPDATE: modify the items (direct)
// DELETE: call delete() on each Row (direct)
// GRANT/REVOKE: modify ACLs (via Security Service)
// ALTER: modify the items (direct) and/or the relations (via
Relationship Service)
// etc.
//
// I'm not sure yet about LOCK and UNLOCK.
//
// </info>
// Query result interface
interface QueryResult {
typedef sequence<Row> type;
typedef sequence<string> headerType;
readonly attribute headerType header;
readonly attribute type data;
Row fetch(in long rownum); // not yet implemented
// zero based numbering of rows
};
// Connected database object
interface Database {
QueryResult exec(in string query);
void disconnect();
};
// Server object (stateless)
interface Server {
Database connect(in string db, in string user, in string password);
};
};
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: [INTERFACES] Updated IDL with considerations for COSS
@ 1998-11-16 15:31 Michael Robinson <robinson@public.bta.net.cn>
1998-11-16 15:41 ` RE: [INTERFACES] Updated IDL with considerations for COSS Taral <taral@cyberjunkie.com>
0 siblings, 1 reply; 5+ messages in thread
From: Michael Robinson @ 1998-11-16 15:31 UTC (permalink / raw)
To: pgsql-interfaces@hub.org; taral@cyberjunkie.com
"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
^ permalink raw reply [nested|flat] 5+ messages in thread
* RE: [INTERFACES] Updated IDL with considerations for COSS
1998-11-16 15:31 Re: [INTERFACES] Updated IDL with considerations for COSS Michael Robinson <robinson@public.bta.net.cn>
@ 1998-11-16 15:41 ` Taral <taral@cyberjunkie.com>
1998-11-16 17:19 ` RE: [INTERFACES] Updated IDL with considerations for COSS The Hermit Hacker <scrappy@hub.org>
0 siblings, 1 reply; 5+ messages in thread
From: Taral @ 1998-11-16 15:41 UTC (permalink / raw)
To: Michael Robinson <robinson@public.bta.net.cn>; pgsql-interfaces@hub.org
> 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.
^ permalink raw reply [nested|flat] 5+ messages in thread
* RE: [INTERFACES] Updated IDL with considerations for COSS
1998-11-16 15:31 Re: [INTERFACES] Updated IDL with considerations for COSS Michael Robinson <robinson@public.bta.net.cn>
1998-11-16 15:41 ` RE: [INTERFACES] Updated IDL with considerations for COSS Taral <taral@cyberjunkie.com>
@ 1998-11-16 17:19 ` The Hermit Hacker <scrappy@hub.org>
0 siblings, 0 replies; 5+ messages in thread
From: The Hermit Hacker @ 1998-11-16 17:19 UTC (permalink / raw)
To: Taral <taral@cyberjunkie.com>; +Cc: Michael Robinson <robinson@public.bta.net.cn>; pgsql-interfaces@hub.org
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
^ permalink raw reply [nested|flat] 5+ messages in thread
* RE: [INTERFACES] Updated IDL with considerations for COSS
@ 1998-11-16 16:01 Michael Robinson <robinson@public.bta.net.cn>
0 siblings, 0 replies; 5+ messages in thread
From: Michael Robinson @ 1998-11-16 16:01 UTC (permalink / raw)
To: pgsql-interfaces@hub.org
"Taral" <taral@cyberjunkie.com> writes:
>module PostgreSQL { // Note we already separate our namespace
> module Types {
> typedef short int2;
> typedef short int4;
> // etc.
> }
Works for me.
>> 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];
I think I meant big-endian (that *is* "network order", isn't it? I always
forget). Anyway, you get the point.
>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.
Well, until it's fairly stable, keep reposting it. That way people don't
have to keep checking for changes in the tree.
-Michael Robinson
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~1998-11-16 17:19 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1998-11-16 03:33 Updated IDL with considerations for COSS Taral <taral@cyberjunkie.com>
1998-11-16 15:31 Re: [INTERFACES] Updated IDL with considerations for COSS Michael Robinson <robinson@public.bta.net.cn>
1998-11-16 15:41 ` Taral <taral@cyberjunkie.com>
1998-11-16 17:19 ` The Hermit Hacker <scrappy@hub.org>
1998-11-16 16:01 RE: [INTERFACES] Updated IDL with considerations for COSS Michael Robinson <robinson@public.bta.net.cn>
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