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