Re: [INTERFACES] IDL :)

"Taral" <taral@cyberjunkie.com> writes:
> Well... SOMEONE comment on this! It's what I've got so far:

This sort of thing would be workable (barely) for the Postgres built-in
types, but I think it falls down badly as soon as you think about
user-defined types, which are after all one of Postgres' strengths.

We need some way of not having to enumerate all the possible field
datatypes in advance.

Bearing in mind that I don't know anything about IDL, here is one
way to attack it:

1. Go ahead and provide explicit representations for the half-dozen
most common datatypes, ie, ints, floats, char strings.  (Don't forget
arrays of these.)

2. Allow any datatype to be transported as a character string, with
necessary conversions happening at the backend (and probably in the
calling application as now).  This corresponds to "ASCII" queries
in the current FE/BE protocol.

3. Allow any datatype to be transported as an uninterpreted binary
byte string, with the calling app responsible for making sense of the
backend's representation.  This corresponds to "binary" queries
in the current protocol.

With an approach like this you don't need direct IDL representation
of anything except ints, floats, and strings.  However, untranslated
binary representations are pretty ugly and untransportable.  So I wonder
whether CORBA doesn't provide some more intelligent way to deal with the
problem of run-time type description.  Surely there's got to be an
explicit run-time representation of type knowledge in CORBA?  The wire
protocol, at least, must have it...

            regards, tom lane