I chose not to declare _seq as type Int because I wanted access to the
entire record and it's columns. The function is a bit longer than just,
really ;-)
Anyway it's more a case of an explicit cast will fix it for now, thanks
for that.
As for the runtime down-conversion. I could see it being handy, but a
little dangerous. I could see it throwing an exception of course when
the down-conversion was impossible, i.e. bigint value exceeds int. So as
you say why bother.
Hadley
On Tue, 2002-12-17 at 13:12, Tom Lane wrote:
> Hadley Willan <hadley.willan@deeper.co.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
--
Hadley Willan > Systems Development > Deeper Design Limited. +64(7)377-3328
hadley.willan@deeper.co.nz > www.deeperdesign.com > +64(21)-28-41-463
Level 1, 4 Tamamutu St, PO Box 90, TAUPO 2730, New Zealand.
