Re: ADTs and embedded sql

From: Thomas Lockhart <lockhart(at)fourpalms(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Tony Griffiths(RA)" <griffitt(at)cs(dot)man(dot)ac(dot)uk>, Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ADTs and embedded sql
Date: 2002-06-21 13:47:41
Message-ID: 3D132E7D.AE124A5F@fourpalms.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 2002-06-21 14:02:27 Re: Idea for the statistics collector
Previous Message Jan Wieck 2002-06-21 13:46:38 Re: Reduce heap tuple header size