Guys,

got this problem in 7.4 beta 2:

treedemo=# SELECT LPAD ((team_name), (LENGTH(team_name) + (3*(tlevel-2)))) AS
teams_display,team_id, lnode
treedemo-# FROM teams
treedemo-# WHERE lnode > 0
treedemo-# ORDER BY lnode;
ERROR: function lpad(character varying, bigint) does not exist

(the above query worked fine in 7.3.4, as I recall)

treedemo=# \df lpad
List of functions
Result data type | Name | Argument data types
------------------+------+---------------------
text | lpad | text, integer
text | lpad | text, integer, text


Now, I've been in favor of reducing problematic implicit conversions. But
VARCHAR --> TEXT is one that needs to stay, as there's no possibility of
ambiguity, and most users count on doing it transparently.

Either that, or we need to build all string function for varchar.

--
Josh Berkus
Aglio Database Solutions
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

Josh Berkus <josh (AT) agliodbs (DOT) com> writes:
Uh, yeah, but we did in 7.2 and 7.3 as well... count() hasn't been
int4 since 7.1...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Tom,

Hmmm ... can't be 7.2. The query is taken from a production database written
for 7.2; I'd have noticed the BIGINT problem before now. Either that, or in
7.2 we were doing implicit conversion from BIGINT to INT for function calls?

However, it's certainly possible it happend in 7.3, as this particular app was
not ported to 7.3.

--
Josh Berkus
Aglio Database Solutions
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

Josh Berkus <josh (AT) agliodbs (DOT) com> writes:
That could be --- I don't recall exactly when we decided implicit
bigint->int conversion was a bad idea ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org

Tom,

Well, it is a bad idea, so I won't argue. Sorry for the false alarm.

--
Josh Berkus
Aglio Database Solutions
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org