On Tue, 25 Mar 2003, Stephan Szabo wrote:
> Okay, I think I've localized the cause (but not a fix).
>
> > name_id bigint not null default 0,
>
> I think the problem occurs with of the hack (mentioned in the last mail)
> because the default expression is of a different type. I think it occurs
> specifically because the default expression is of a by value type and the
> real type is by reference, but I haven't gone through enough tests to be
> sure (it works if I make the default a bigint, a timestamp column with a
> timestamptz expression works but an abstime doesn't)
>
> Short term workaround is to make the default expression of the same type
> as the column rather than merely something that can be converted to
> that type.
Well, you're right, here is my workaround:
-- purpose: workaround the dumb value to bigint conversion of postgresql
:)
-- usage getmebigint(int);
drop FUNCTION getmebigint(int);
CREATE FUNCTION getmebigint(int) RETURNS bigint AS
'DECLARE
id bigint;
BEGIN
select $1 into id;
RETURN id;
END;'
language 'plpgsql';
And in table definitions you use getmebigint(0) that makes the
transformation between value type and bigint type
name_id bigint not null default getmebigint(0),
Awful but is working until you'll find the problem.
Question: there isn't any cast operator like this?:
name_id bigint not null default bigint(0)
Anyway, thankz for the fast reply.
Regards,
Adrian Pop
