From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hadley Willan <hadley(dot)willan(at)deeper(dot)co(dot)nz> |
Cc: | Postgresql General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Changing a column's type |
Date: | 2002-12-17 00:12:54 |
Message-ID: | 29983.1040083974@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hadley Willan <hadley(dot)willan(at)deeper(dot)co(dot)nz> writes:
> FUNCTION fn_create_new_item()
> _seq RECORD;
> begin
> SELECT INTO _seq NEXTVAL(''source_sequence'');
> ..do stuff, insert ....
> PERFORM fn_b( _seq.next_value );
> end;
> Call to fn_b breaks because _seq.next_value is of type BIGINT.
Oh, I see. It seems like a rather random coding technique: why'd you
not declare _seq as type int? If you don't want to change that, you
could insert an explicit cast in the PERFORM, too:
PERFORM fn_b( _seq.next_value::int );
There's been some recent talk of allowing fn_b() with an int8 argument
to be resolved as fn_b(int4) --- with a runtime down-conversion --- if
there are no other candidates for fn_b(). But no one's put forward a
convincing argument for that as yet. It might just add confusion.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Hadley Willan | 2002-12-17 00:17:40 | Re: Changing a column's type |
Previous Message | scott.marlowe | 2002-12-17 00:12:24 | Server testing. |