From: | Adrian Pop <adrpo(at)ida(dot)liu(dot)se> |
---|---|
To: | Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Postgresql 7.3.2 Crash |
Date: | 2003-03-26 11:14:50 |
Message-ID: | Pine.GSO.4.53.0303261203470.16313@mir20.ida.liu.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Rubio | 2003-03-26 13:02:40 | Re: Can't connect to my postgresql |
Previous Message | Daniel Rubio | 2003-03-26 07:49:15 | Re: Can't connect to my postgresql |