From: | Richard Huxton <dev(at)archonet(dot)com> |
---|---|
To: | Michal Hlavac <hlavki(at)medium13(dot)sk> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Stored procedure failure |
Date: | 2004-08-26 10:16:55 |
Message-ID: | 412DB897.5090804@archonet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Michal Hlavac wrote:
> hello, I have interesting problem...
>
> I have stored procedure, which works good, but only if input is "correct".
> Correct input is, when $1 is id, which exists in table...
> If I put non exists id, database fall down and restart with this error:
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
>
> I think, that problem is in line:
> FOR tmp_row IN SELECT v_name FROM c_part_cat WHERE v_path @> my_path
> ORDER BY v_path LOOP
> because without them it works well...
> CREATE OR REPLACE FUNCTION "public"."get_part_cat_path" (integer)
> RETURNS text AS'
> DECLARE
> my_path ltree;
...
> BEGIN
> SELECT v_path INTO my_path FROM c_part_cat WHERE i_part_cat_id = $1;
> result := ''''; first := true;
> FOR tmp_row IN SELECT v_name FROM c_part_cat WHERE v_path @> my_path
I'm guessing a problem with the ltree code. Presumably in handling the
null my_path.
> Version: 7.4.5 and 7.4.3 (both versions have this problem)
Looking at the 8.0beta source, the functions (...ltree_isparent) are all
marked strict so they should just return null on a null parameter.
What happens if you set my_path to some non-null but un-matched value
before the problem line?
--
Richard Huxton
Archonet Ltd
From | Date | Subject | |
---|---|---|---|
Next Message | Michal Hlavac | 2004-08-26 10:23:25 | Re: Stored procedure failure |
Previous Message | Michal Hlavac | 2004-08-26 10:15:48 | Re: Stored procedure failure |