Re: Catalogs design question

From: "Steve Howe" <howe(at)carcass(dot)dhs(dot)org>
To: "Haller Christoph" <ch(at)rodos(dot)fzk(dot)de>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Catalogs design question
Date: 2001-10-28 05:56:28
Message-ID: 005b01c15f75$4990c000$8430b0c8@angla
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello Haller!!!
> Your question about - pg_proc
> select t.typname from pg_type t , pg_proc p
> where p.proname = '<your_stored_procedure>' and p.proargtypes[0] = t.oid ;
> select t.typname from pg_type t , pg_proc p
> where p.proname = '<your_stored_procedure>' and p.proargtypes[1] = t.oid ;
> ...
> select t.typname from pg_type t , pg_proc p
> where p.proname = '<your_stored_procedure>' and p.proargtypes[7] = t.oid ;
>
> As far as I understand the proargtypes entries 0 means no further
parameter.
> This oidvector type of proargtypes seems to have a start index of 0.
> As long as there are at maximum 8 parameters allowed, this looks
practicable.
There is no limit on the number of arguments. An user could create a weird
function like this:

howe=# CREATE FUNCTION test2(int2, int2, int2, int2, int2, int2, int2, int2,
int2, int2, int2, int2, int2) RETURNS int4
AS 'SELECT 1 AS RESULT' LANGUAGE 'sql';
CREATE

and it would be allowed...

howe=# select proargtypes from pg_proc where proname='test';
proargtypes
----------------------------------------
21 21 21 21 21 21 21 21 21 21 21 21 21
(1 row)

Again, the problem is that I can't predict (nor limit) what users will try
to do...

Best Regards,
Steve Howe

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-10-28 06:24:03 Re: pgindent run
Previous Message mlw 2001-10-28 03:38:53 Optimizer, index use, good news for 7.2b1