Josh Berkus <josh@agliodbs.com> writes:
>> 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.
> Hmmm? I thought that Dann was just talking about constants, and not column
> results. Am I confused?
Well, the specific example he was on about was a constant, but I don't
think it does him any good for us to fix just that one case. He'll
still have to deal with columns of indeterminate width in a whole lot of
other cases. If there were a reasonable path for us to report a useful
width bound in *every* case, then I could see spending time on it ...
but there's not.
BTW, it would certainly be trivial to extend libpq to report the actual
max width of a column within an already-retrieved PGresult. This isn't
anything the client code can't compute for itself, of course, but libpq
could get it in somewhat fewer cycles. However, I'm under the
impression that Dann wants the number at statement prepare time, and
we simply haven't got the information then.
> I'd think it would be possible to do this in an abstract way ... having a
> "DisplayLength()" call for each data type and value. That would require
> casting the constant, though, or computing all uncast constants as text.
No, the point is about predicting the max width of a column of a query
result in advance of actually running the query. After you've got the
values in hand, it's not a very interesting problem. Before, well,
consider these examples:
select repeat(text_col, int_col) from my_table;
select repeat(text_col, int_col * random()) from my_table;
select repeat(text_col, some_user_defined_function(int_col)) from my_table;
The problem's really not soluble unless you want to dumb Postgres down
to approximately the capabilities of SQL89 -- no user-defined functions,
let alone user-defined types, plus pull out a whole lot of the built-in
functions that don't have readily predictable result widths.
regards, tom lane
