Subject: Strange replace behaviour (BUG)

From: "Schenkelaars.V.F" <[email-masked]>
Date: Tue, 18 Aug 92 13:36:05 MET DST

I'v encountered a strange bug in postgres. I've defined
a function as follows:

define function reactinsert (language = "c", returntype = int4)
   as "/fusr/vfsj3/postgres/reactive/reactree.o"

This results in the following tuple:

Query sent to backend is "retrieve (pg_proc.all) where pg_proc.proname ~ "react""
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| proname     | proowner    | prolang     | proisinh    | proistrusted| proiscachable| pronargs    | proretset   | prorettype  | proargtypes | probyte_pct | properbyte_cpu| propercall_cpu| prooutin_ratio| prosrc      | probin      |
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| reactinsert | 123         | 13          | f           | f           | f           | 0           | f           | 23          | 0 0 0 0 0 0 0 0| 100         | 10          | 100         | 1           | -           | /fusr/vfsj3/postgres/reactive/reactree.o|
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

but when I replace the pronargs atrtribute like: 

replace pg_proc (pronargs = 2) where pg_proc.proname = "reactinsert"

And I look in the pg_proc table I get:

Query sent to backend is "retrieve (pg_proc.all) where pg_proc.proname ~ "react""
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| proname     | proowner    | prolang     | proisinh    | proistrusted| proiscachable| pronargs    | proretset   | prorettype  | proargtypes | probyte_pct | properbyte_cpu| propercall_cpu| prooutin_ratio| prosrc      | probin      |
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| reactinsert | 123         | 13          | f           | f           | f           | 2           | f           | 23          | 0 0 0 0 0 0 0 0| 100         | (null)      | (null)      | (null)      | (null)      | (null)      |
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

A number of attributes has changed too. Is this a bug or something else?

Greetings

     ____________________
 \  / . _   _  _   _  |
  \/ ( ( \ (_ (-' ( \ |

--------------------------------------------------------------------------------
Vincent F. Schenkelaars				|
Company: FEL-TNO                                | Private:
Email  : [email-masked]	|
address: Oude Waalsdorperweg 63			| Groenhovenstraat 12
         Postbus 96864				|
         2509 JG  Den Haag			| 2311 BT  Leiden
         The Netherlands			| The Netherlands
Phone  : Holland 070-3264221			| Holland 071-125576
Fax    : Holland 070-3280961			|
--------------------------------------------------------------------------------
We apologize for the inconvenience.

---

From: <[email-masked]>
Date: Tue, 18 Aug 92 12:33:08 PDT

In message <[email-masked]> you write:

> 	[ ... ]
>	[ ... ]
>      | (null)      | (null)      | (null)      | (null)      | (null)      |
> 

vincent,

this is a bug in the system catalogs for postgres 4.0 that has been
fixed in the current system.  the problem is that the number of attributes
recorded for pg_proc in pg_class is wrong.  if you do

    retrieve (pg_class.relnatts) where pg_class.relname = "pg_proc"

you'll see that only eleven attributes are declared.  this should be
sixteen.  you should be able to repair the problem by doing

    replace pg_class (relnatts = 16) where pg_class.relname = "pg_proc"

and killing and restarting your postmaster.  you should do this in
each database you have created, and you should do it in the template1
database.  changing template1 will cause all future databases you
create to have the right value.

					mike