Subject: query interface

From: [email-masked]
Date: Tue, 11 Aug 92 11:56:07 -0700

From: Deborah Swanberg <[email-masked]>

   I'm interested in developing a code structured, rather than
   string structured, interface to Postgres for submitting queries.
   It doesn't quite make sense to me that my interface should 
   have to translate data structures to string, and then that Postgres 
   should have to translate from string to data structures.
   A code structured interface would require interfacing at a
   lower level to Postgres.

   Comments?

Why bother? Having a well defined interface, like the query strings,
really buys you a lot, for debugging and ease of program changes.
The cycles wasted in assembling a command and parsing it is not an
issue on a modern workstation.

..of course this was not what you would like to hear, so good luck.

/Tommy Thorn

---

From: Chris Flatters <[email-masked]>
Date: Tue, 11 Aug 92 13:14:00 -0700

> issue on a modern workstation.

Firstly, the overhead of assembling a command can be a serious overhead
in some applications.  Suppose that we have an uncalibrated scientific
data set stored in a POSTGRES table.  For the sake of argument suppose
that each item contains one measurement stored a single real number and
the other fields record the time at which the measurement was taken and
other information that identifies the measurement.  In order to calibrate
the data we must multiply the real number by an externally derived number
that varies from measurement from measurement.  The straightforward way
of doing this requires generating a query string for every data item.  If
there are very many data items the cost of doing this can be prohibitive
(converting numeric data to text is very expensive) and some scientific
applications can involve 1e5 or more data items.

The alternative is to use a binary copy to copy the calibration factors
into a seperate POSTGRES table and apply them to the original data,
generating a new POSTGRES table.  This may be ruled out in some cases
by the size of the data sets (some scientific datasets may have storage
requirements of the order of a gigabyte or more).

Secondly, converting floating-point numbers to text and back again
can incurr a loss of precision.  This may be critical in some scientific
applications.  Fortunately this is not a problem on machines that
implement IEEE-754 binary floating-point arithmetic.

	Chris Flatters
	[email-masked]

---

From: Deborah Swanberg <[email-masked]>
Date: Tue, 11 Aug 92 14:57:17 -0700

Tom, you are right, CPU cyles are something we don't need
to worry about, generally.  CPU cycles do become an issue, however,
when the object is 100M.  But Postgres offers the large file
paradigm which permits untranslated blocks to be passed.

I'm working with images, sound, etc.  Having to convert
this data to a string just to communicate to the database
is an extra, unnecessary step I hate wasting the PROGRAMMING
cycles on.  

But along a more philosophical line, I don't believe the 
text-string interface is an appropriate interface when working with 
non-alphanumeric data.  The string interface is a good tool
when alphanumeric data is to be displayed, it offers the developers the
freedom from having to code the string translation themselves.  But
databases are being used to store and manage new types of data which no
longer fit the string paradigm.  They should evolve to meet the needs
of new applications and systems, rather than remaining in the world of
teletype forever.

I'm just beginning to explore this, and rather than waste my time
duplicating effort, I was wondering if someone might have solved parts
of this problem.  I know others are working on similar issues,
especially as the sequoia project is looking to working with images for
global warming.

> 
> 
> 
> 
> From daimi.aau.dk!tthorn Tue Aug 11 17:22:09 1992
> Date: Tue, 11 Aug 92 11:56:07 -0700
> From: [email-masked]
> To: [email-masked]
> Message-Id: <[email-masked]>
> Subject: query interface
>