Thread: ADTs and embedded sql

Hi,
I've a question about returning ADT values through embedded SQL. It's 
fine to retrieve values of PostgreSQL's build-in types in to C variables 
of roughly the same type, with only (possibly) a  small impedance 
mismatch. However when we want to retrieve into values of the ADTs, 
i.e., the geometric types, it looks like we have to retrieve them into 
strings, and then manually convert them into the correct type - if this 
is not the case then a posting of how to do this into variables of the 
correct type would be great. This means that:

a) The client-side programmer has to be responsible for parsing the 
returned string, which could cause problems if the output format of the 
ADT is changed, and

b) The impedance mismatch is much greater than that of the built-in types.

Are there any plans to extend the ADT registration process to allow 
output of the actual type (not just the string) (I seem to remember that 
INGRES did this a while ago, with admittedly a much more complex 
registration process), and also for ecpg to be able to correctly parse 
variables other than those built into the database kernel.

Many thanks,

Tony

> a) The client-side programmer has to be responsible for parsing the
> returned string, which could cause problems if the output format of the
> ADT is changed, and

So we need a convention for building client-side libraries.

> b) The impedance mismatch is much greater than that of the built-in types.

A first step would be to make the structure definitions and i/o code for
UDTs available to the client. Perhaps the next step could involve using
those definitions internally in ecpg. But without the first step we
don't have much to build on.
                      - Thomas

"Tony Griffiths(RA)" <griffitt@cs.man.ac.uk> writes:
> a) The client-side programmer has to be responsible for parsing the 
> returned string, which could cause problems if the output format of the 
> ADT is changed, and

You seem to be proposing that we instead expose the internal storage
format of the ADT, which seems to me to be much more likely to change
than the string representation.  (Not to mention that it will open up a
host of platform compatibility issues --- endianness, struct packing,
float format rules for example.)

To give just one example, as of 7.3 there will be two entirely different
internal formats for the datetime-related types.  A client would have
to be prepared to cope with that, on top of possible endian and float
format differences between server and client machines.

Parsing the string representation may be an annoyance, but I suspect
it is the lesser evil.
        regards, tom lane

At 01:49 PM 6/20/02 +0100, Tony Griffiths(RA) wrote:

>a) The client-side programmer has to be responsible for parsing the 
>returned string, which could cause problems if the output format of the 
>ADT is changed, and
>
>b) The impedance mismatch is much greater than that of the built-in types.

One man's impedance mismatch is another man's layer of abstraction / 
interface :).

Sorry - couldn't resist ;).

Cheerio,
Link.

> > a) The client-side programmer has to be responsible for parsing the
> > returned string, which could cause problems if the output format of the
> > ADT is changed, and
> You seem to be proposing that we instead expose the internal storage
> format of the ADT, which seems to me to be much more likely to change
> than the string representation.  (Not to mention that it will open up a
> host of platform compatibility issues --- endianness, struct packing,
> float format rules for example.)

That is one possibility, but I think the proposal is to expose the
*support* for the data types to client-side apps. So we would have
librar(ies) which allow parsing the stringified representation of a
value into an acceptable internal format on the client, along with some
support code for working with the values.

That is a Good Idea in principle. In practice, someone would need to
take ownership of the project and develop an style and technique for
packaging support for data types in this way...
                     - Thomas

Thomas Lockhart <lockhart@fourpalms.org> writes:
> That is one possibility, but I think the proposal is to expose the
> *support* for the data types to client-side apps.

Ah, I see --- more or less make all of utils/adt/ available to be
linked into clients.

> That is a Good Idea in principle. In practice, ...

Yeah, it'd be a huge amount of work.  For starters, all that code
relies on the backend environment for error handling and memory
management...
        regards, tom lane

> Ah, I see --- more or less make all of utils/adt/ available to be
> linked into clients.
> > That is a Good Idea in principle. In practice, ...
> Yeah, it'd be a huge amount of work.  For starters, all that code
> relies on the backend environment for error handling and memory
> management...

It would be a large amount of work to make *all* of utils/adt available.
However, the initial work would be to support I/O to get values
converted to internal storage. Michael M. already has to do some of this
for ecpg, and presumably we could do this for more types (or maybe *all*
builtin types are already supported in this way by ecpg, in which case
MM has already done all of the hard work, and we might just repackage
it).

A first cut would seem to be appropriate, if someone would like to pick
up the work. Tony?? ;)
                   - Thomas

Thomas Lockhart wrote:
> 
> > Ah, I see --- more or less make all of utils/adt/ available to be
> > linked into clients.
> > > That is a Good Idea in principle. In practice, ...
> > Yeah, it'd be a huge amount of work.  For starters, all that code
> > relies on the backend environment for error handling and memory
> > management...
> 
> It would be a large amount of work to make *all* of utils/adt available.
> However, the initial work would be to support I/O to get values
> converted to internal storage. Michael M. already has to do some of this
> for ecpg, and presumably we could do this for more types (or maybe *all*
> builtin types are already supported in this way by ecpg, in which case
> MM has already done all of the hard work, and we might just repackage
> it).
> 
> A first cut would seem to be appropriate, if someone would like to pick
> up the work. Tony?? ;)

I'd love to get involved in this, BUT... no time at the moment, although
if I get a really good Masters student  next semester - I could always
do this as their project. If this is still a requirement in about 3
months then I can set someone on to it.

Tony

> 
>                     - Thomas
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
> 
> http://www.postgresql.org/users-lounge/docs/faq.html

-- 
Tony

---------------------------------
Dr. Tony Griffiths
Research Fellow
Information Management Group,
Department of Computer Science,
The University of Manchester,
Oxford Road,
Manchester M13 9PL, 
United Kingdom

Tel. +44 (0) 161 275 6139
Fax +44 (0) 161 275 6236
email tony.griffiths@cs.man.ac.uk
---------------------------------