Re: [BUGS] Implicit conversion bugaboo in beta2?

2003-09-14 Thread Josh Berkus
Tom, > That could be --- I don't recall exactly when we decided implicit > bigint->int conversion was a bad idea ... 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)

Re: [BUGS] Implicit conversion bugaboo in beta2?

2003-09-14 Thread Tom Lane
Josh Berkus <[EMAIL PROTECTED]> writes: >> Uh, yeah, but we did in 7.2 and 7.3 as well... count() hasn't been >> int4 since 7.1... > 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

Re: [BUGS] Implicit conversion bugaboo in beta2?

2003-09-14 Thread Josh Berkus
Tom, > Uh, yeah, but we did in 7.2 and 7.3 as well... count() hasn't been > int4 since 7.1... 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 BI

Re: [BUGS] Implicit conversion bugaboo in beta2?

2003-09-14 Thread Tom Lane
Josh Berkus <[EMAIL PROTECTED]> writes: > Are we now defaulting COUNT(*) to BIGINT? 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

Re: [BUGS] Implicit conversion bugaboo in beta2?

2003-09-14 Thread Josh Berkus
Tom, > regression=# select lpad('xyz'::varchar, 4::int8); > ERROR: Function lpad(character varying, bigint) does not exist > Unable to identify a function that satisfies the given argument > types You may need to add explicit typecasts Oops! Sorry. The problem is there, it's just somet

Re: [BUGS] Implicit conversion bugaboo in beta2?

2003-09-14 Thread Tom Lane
Josh Berkus <[EMAIL PROTECTED]> writes: > ERROR: function lpad(character varying, bigint) does not exist > (the above query worked fine in 7.3.4, as I recall) Really? I get regression=# select lpad('xyz'::varchar, 4::int8); ERROR: Function lpad(character varying, bigint) does not exist

[BUGS] Implicit conversion bugaboo in beta2?

2003-09-14 Thread Josh Berkus
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 abov

Re: [BUGS] PostgreSql 7.3.4 & 7.4 on MacOS X

2003-09-14 Thread Tom Lane
[EMAIL PROTECTED] (Payman) writes: > Hey tom and your PowerBook ??? I had it back for a day, and it went belly up again :-( regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an

[BUGS] PostgreSql 7.3.4 & 7.4 on MacOS X

2003-09-14 Thread Payman
Hi all, Probleme with 7.3.4 & 7.4 with gcc 3.3 imposible to compile it, probleme with bsd headers files... Param.h, ... but with gcc 3.1 all compile and work nice % sudo /usr/sbin/gcc_select 3.1 i compile & install 7.4 with many difficulty changing shared memory sizes ... shmmax shmall ... in

Re: [BUGS] wrong inicializied array in plpgsql

2003-09-14 Thread Tom Lane
Pavel Stehule <[EMAIL PROTECTED]> writes: > I am testing long array values. I tryed write simple function in plpgsql > for this. I found maybe a bug. Array in plpgsql without explicit init > (empty array) don't work; This isn't a bug; or at least, it's not plpgsql's fault. The array variable is

[BUGS] wrong inicializied array in plpgsql

2003-09-14 Thread Pavel Stehule
Hello I am testing long array values. I tryed write simple function in plpgsql for this. I found maybe a bug. Array in plpgsql without explicit init (empty array) don't work; CREATE OR REPLACE FUNCTION foo1() RETURNS FLOAT AS ' DECLARE f FLOAT []; BEGIN f[1] := 10.0; RETURN f[1]; END' LANGU