Re: Selecting a constant question: A summary - Mailing list pgsql-hackers

As Dann pointed out we were one of the first companies to port Postgres
to windows many many years ago (7.1 days), and part of that porting work
is in the current postgresql product.

As I pointed out in a prior post, for the ODBC specification at least
(probably others), a maximum upper bound on returned data *must* be
reported and determined ahead of time when using binding ... A technique
where the client application allocates memory for the data and supplies
a pointer to that memory location for the driver.

Postgres unlike other databases shifts the burden of determining this
maximum size to the client and/or driver.  Our company specializes in
access to wide variety of databases, both relational and non relational,
including SQL Server, Oracle, DB2, Sybase, Informix, etc.  Postgres
sticks out as the only database that we have encountered with this
behavior .. Which is why we posted the original message.

Also as Dann pointed out even if this issue was addressed, it does not
help us because every existing installation of Postgres has the metadata
bug, so we *have* to bandaid it at the client/driver level anyway.

At least we have a record of the issue, so the next time a developer in
the community runs across the same oddity hopefully they will find this
and won't be scratching their heads like we were for a bit :)

Thanks

lm

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Tuesday, June 12, 2007 3:11 PM
To: Dann Corbit
Cc: pgsql-hackers@postgresql.org; Larry McGhaw
Subject: Re: [HACKERS] Selecting a constant question: A summary

"Dann Corbit" <DCorbit@connx.com> writes:
> In the case of a SELECT query that selects a fixed constant of any
> sort, it would be a definite improvement for PostgreSQL to give some
> sort of upper maximum.

What's the point?  You keep reminding us that your code is middleware
that can't assume anything much about the queries you're dealing with.
Therefore, I see no real value in fixing up one corner case.  Your
argument about space allocation falls to the ground unless we can
provide a guaranteed, and usefully tight, upper bound on the column
width in *every* situation.  If we cannot (which we can't), you're still
going to need those client-side "kluges".

In my opinion, variable-length data is a fact of life and you should
endeavor to make your code deal with it gracefully.  There are bits of
the SQL spec that assume fixed-width data specifications are useful, but
to be blunt that's all a holdover from 1960s 80-column-punch-card
thinking.  It's no way to design a modern application.

BTW, the reason I'm resistant to even thinking about this is that
Postgres is designed as an extensible system.  Trying to do what you
want is not a matter of fixing literal constants and concatenation and
one or two other places --- it's a matter of imposing a new and
potentially hard-to-meet requirement on every datatype under the sun,
including a lot of user-written code that we don't control and would
break by adding such a requirement.  So it's not even likely that we'd
think very hard about making this work, let alone actually do it.
        regards, tom lane