Re: Changing a column's type
От | Hadley Willan |
---|---|
Тема | Re: Changing a column's type |
Дата | |
Msg-id | 1040084260.2931.33.camel@orac обсуждение исходный текст |
Ответ на | Re: Changing a column's type (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
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.
В списке pgsql-general по дате отправления: