question about the design consideration for system catalogs

From: "Tao Ma" <feng_eden(at)163(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: question about the design consideration for system catalogs
Date: 2009-02-24 03:30:47
Message-ID: gnvpl3$62p$1@news.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Howdy,

I have a question about the design consideration for system catalogs.
Some of tables include arrays to hold the variable informations, such
as tracking the procedure declaration informations in pg_proc. To store
the informations for procedure parameters, there are proargtypes,
proallargtypes, proargmodes and proargnames colums.
Store the parameters in this way is much easier to access these
informations for backend developper. Each procedure informations can be
retrieved just in one query and store them in the Form_pg_proc structure
directly.
But if I wanna check the parameter informations, it's a little hard to
read. If I wanna write a program to re-construct the procedure source
code, it is not convenience to access the parameter informations from
the front-end. What cons are there If store the procedure and its
parameters in different tables(e.g. pg_attribute and pg_attrdef)? Access
two tables is slower than access one tables? It needs more code to
access the procedure informations?
I think store them separately is more common.

TIA

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message pi song 2009-02-24 04:20:33 Re: Hadoop backend?
Previous Message Tom Lane 2009-02-24 01:43:02 Re: Okay to change TypeCreate() signature in back branches?