BUG #2905: min and max return incorrect text type

Adriaan van Os wrote:

The following bug has been logged online:

Bug reference: 2905
Logged by: Adriaan van Os
Email address: postgres@microbizz.nl
PostgreSQL version: 8.1.4
Operating system: Mac OS X 10.4.6, intel
Description: min and max return incorrect text type
Details:

Table 9-37. Aggregate Functions in the Postgres docs states that the return
type for min and max is the "same as argument type".

However, min(VARCHAROID) and max(VARCHAROID) return TEXTOID as a result
type.

Yea, they are internally treated as very similar types.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:

Adriaan van Os wrote:

The following bug has been logged online:

Bug reference: 2905
Logged by: Adriaan van Os
Email address: postgres@microbizz.nl
PostgreSQL version: 8.1.4
Operating system: Mac OS X 10.4.6, intel
Description: min and max return incorrect text type
Details:

Table 9-37. Aggregate Functions in the Postgres docs states that the return
type for min and max is the "same as argument type".

However, min(VARCHAROID) and max(VARCHAROID) return TEXTOID as a result
type.

Yea, they are internally treated as very similar types.

But "internally treated as very similar" is still not "same as argument type". Computing requires
exactness.

Adriaan van OS

Adriaan van Os wrote:

However, min(VARCHAROID) and max(VARCHAROID) return TEXTOID as a
result type.

Yea, they are internally treated as very similar types.

But "internally treated as very similar" is still not "same as
argument type". Computing requires exactness.

Aside from the apparent discrepancy between the documentation and the
actual behavior, is there an actual use case where this is a problem?

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:

Adriaan van Os wrote:

However, min(VARCHAROID) and max(VARCHAROID) return TEXTOID as a
result type.

Yea, they are internally treated as very similar types.

But "internally treated as very similar" is still not "same as
argument type". Computing requires exactness.

Aside from the apparent discrepancy between the documentation and the
actual behavior, is there an actual use case where this is a problem?

Dijkstra's "Rule 0: Don�t Make a Mess of It� <http://www.cs.utexas.edu/users/EWD/&gt; and the virtues
of strong typing, which, for SQL, imply checks at runtime <http://en.wikipedia.org/wiki/Type_safety&gt;.

Besides, the question is absurd. I stumble over a stone on the road, report it and then you ask "is
there an actual use case where this is a problem". Why else do I report it ? What you probably
wanted to ask is: "Apart from the missing warning along the road, couldn't you have walked around
that stone ?"

Well, in answer to that last question, I could have, but that is the wrong approach to computing.

Regards,

Adriaan van Os

Peter Eisentraut wrote:

Adriaan van Os wrote:

However, min(VARCHAROID) and max(VARCHAROID) return TEXTOID as a
result type.

Yea, they are internally treated as very similar types.

But "internally treated as very similar" is still not "same as
argument type". Computing requires exactness.

Aside from the apparent discrepancy between the documentation and the
actual behavior, is there an actual use case where this is a problem?

No, I don't think so, and I am reluctant to adjust the documentation to
say "or similar".

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce@momjian.us> writes:

Peter Eisentraut wrote:

Aside from the apparent discrepancy between the documentation and the
actual behavior, is there an actual use case where this is a problem?

No, I don't think so, and I am reluctant to adjust the documentation to
say "or similar".

The documentation is correct as it stands: max(text) returns text.
Adriaan's complaint about max(varchar) is off base because there is
no such function.

regards, tom lane

Adriaan van Os wrote:

Besides, the question is absurd. I stumble over a stone on the road,
report it and then you ask "is there an actual use case where this is
a problem". Why else do I report it ? What you probably wanted to ask
is: "Apart from the missing warning along the road, couldn't you have
walked around that stone ?"

No, I'm asking what kind of stone it was and why it is a problem.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

Peter Eisentraut wrote:

Aside from the apparent discrepancy between the documentation and the
actual behavior, is there an actual use case where this is a problem?

No, I don't think so, and I am reluctant to adjust the documentation to
say "or similar".

The documentation is correct as it stands: max(text) returns text.
Adriaan's complaint about max(varchar) is off base because there is
no such function.

No, the documentation says that the Argument Type of max and min can be "any array, numeric,
string, or date/time type" and that the Return type is the "same as argument type". The functions
min and max applied to a field of type varchar return a function result of type text. So, if a
max(varchar) function is missing and the cause of the text result type is implicit type casting,
then the fact that there is no max(varchar) function is exactly the bug.

Adriaan van Os

Adriaan van Os wrote:

Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

Peter Eisentraut wrote:

Aside from the apparent discrepancy between the documentation and the
actual behavior, is there an actual use case where this is a problem?

No, I don't think so, and I am reluctant to adjust the documentation to
say "or similar".

The documentation is correct as it stands: max(text) returns text.
Adriaan's complaint about max(varchar) is off base because there is
no such function.

No, the documentation says that the Argument Type of max and min can be
"any array, numeric, string, or date/time type" and that the Return type is
the "same as argument type". The functions min and max applied to a field
of type varchar return a function result of type text. So, if a
max(varchar) function is missing and the cause of the text result type is
implicit type casting, then the fact that there is no max(varchar) function
is exactly the bug.

Do you have a specific situation on which this causes a problem for you?
I mean, are you asking because it really bugs you, or just for the sake
of being pedantic?

--
Alvaro Herrera Valdivia, Chile ICBM: S 39� 49' 18.1", W 73� 13' 56.4"
Tulio: oh, para qu� servir� este boton, Juan Carlos?
Policarpo: No, al�jense, no toquen la consola!
Juan Carlos: Lo apretar� una y otra vez.

Alvaro Herrera wrote:

Adriaan van Os wrote:

Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

Peter Eisentraut wrote:

Aside from the apparent discrepancy between the documentation and the
actual behavior, is there an actual use case where this is a problem?

No, I don't think so, and I am reluctant to adjust the documentation to
say "or similar".

The documentation is correct as it stands: max(text) returns text.
Adriaan's complaint about max(varchar) is off base because there is
no such function.

No, the documentation says that the Argument Type of max and min can be
"any array, numeric, string, or date/time type" and that the Return type is
the "same as argument type". The functions min and max applied to a field
of type varchar return a function result of type text. So, if a
max(varchar) function is missing and the cause of the text result type is
implicit type casting, then the fact that there is no max(varchar) function
is exactly the bug.

Do you have a specific situation on which this causes a problem for you?
I mean, are you asking because it really bugs you, or just for the sake
of being pedantic?

And what suggestion do you have for a change? How would you like the
documentation wording changed?

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +