Thread: Can't cast bigint to smallint?
The minor featurette seems to have crept into current sources; it is probably the cause of pg_dump being unable to reinstate disabled triggers. ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Philip Warner <pjw@rhyme.com.au> writes:
> The minor featurette seems to have crept into current sources; it is
> probably the cause of pg_dump being unable to reinstate disabled triggers.
Huh? There's never been a cast from int8 to int2. I checked 7.0 and
7.1, they both complain as well:
test71=# select 8::int8::int2;
ERROR: Cannot cast type 'int8' to 'int2'
Where exactly is pg_dump failing?
regards, tom lane
Philip Warner <pjw@rhyme.com.au> writes:
> At 16:09 24/10/01 -0400, Tom Lane wrote:
>> Huh? There's never been a cast from int8 to int2. I checked 7.0 and
>> 7.1, they both complain as well:
> Is this a policy decision, or just a case where noone has had a chance to
> do it?
Just a missing feature. The code additions would be trivial --- but
would require an initdb to add the catalog entries. I'm loath to do it
so close to beta.
>> Where exactly is pg_dump failing?
> The problem in in the code to re-enable triggers:
> ...reltriggers = (select Count(*)....
> So perhaps this version now has Count returning a bigint rather than an int?
Yes, that's what changed. Perhaps change the code to look like (select count(*)::integer ...
On the other hand, that's no answer for people trying to load existing
dump files into 7.2.
Perhaps we should just do another catalog update and not worry about it.
We just had one earlier this week, so I suppose another wouldn't make
all that much difference. Comments?
regards, tom lane
At 16:09 24/10/01 -0400, Tom Lane wrote: > >Huh? There's never been a cast from int8 to int2. I checked 7.0 and >7.1, they both complain as well: > Is this a policy decision, or just a case where noone has had a chance to do it? >Where exactly is pg_dump failing? > The problem in in the code to re-enable triggers: ...reltriggers = (select Count(*).... So perhaps this version now has Count returning a bigint rather than an int? ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
At 19:41 24/10/01 -0400, Tom Lane wrote: >We just had one earlier this week, so I suppose another wouldn't make >all that much difference. Comments? My pref would be for the initdb; the current situation may break (other) existing apps. ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Philip Warner <pjw@rhyme.com.au> writes:
> The problem in in the code to re-enable triggers:
> ...reltriggers = (select Count(*)....
> So perhaps this version now has Count returning a bigint rather than an int?
Okay, I've added conversion functions for int8-to-int2 and vice versa.
regards, tom lane