From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Hans-Jürgen Schönig <postgres(at)cybertec(dot)at> |
Cc: | pgsql-hackers(at)postgresql(dot)org, eg(at)cybertec(dot)at |
Subject: | Re: Question about "Unrecognized SPI code" ... |
Date: | 2005-02-22 18:33:02 |
Message-ID: | 11181.1109097182@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <postgres(at)cybertec(dot)at> writes:
> ERROR: SPI_execute_plan failed executing query "INSERT INTO
> view_nonsense VALUES (10, 20)": Unrecognized SPI code 0
> CONTEXT: PL/pgSQL function "debug" line 4 at SQL statement
> SPI_result_code_string(int code) and PL/pgSQL don't seem to be aware of
> DO NOTHING rules.
Hmm. What's happening is that _SPI_execute_plan() initializes its local
result variable to 0, and then that ends up getting returned because the
execute-one-query loop executes zero times. Since 0 isn't a defined SPI
result code, this seems bad.
The question is what to return instead. Of the currently defined SPI
result codes, SPI_OK_UTILITY seems the closest, but it implies that
something happened when nothing did. Is it worth inventing a new
result code SPI_OK_NOTHING (or similar) to describe this case? That
would possibly imply changing a lot of SPI-using code to handle the
new result alternative.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Pflug | 2005-02-22 18:42:59 | Re: Get rid of system attributes in pg_attribute? |
Previous Message | Keith Worthington | 2005-02-22 18:22:07 | Question on TRUNCATE privleges |