Re: [HACKERS] question about the design consideration for system catalogs
Tao Ma feng_e...@163.com writes: 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)? Loss of backwards compatibility, for one thing. We're not going to redesign those catalogs just because somebody thinks some other layout would be more convenient for one purpose --- it would break a lot of code for little gain. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] question about the design consideration for system catalogs
Tom Lane t...@sss.pgh.pa.us wrotes: Tao Ma feng_e...@163.com writes: 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)? Loss of backwards compatibility, for one thing. We're not going to redesign those catalogs just because somebody thinks some other layout would be more convenient for one purpose --- it would break a lot of code for little gain. Thank you. Actually, I don't want to change anything. I am curious why we use this form, such as it is easy to access the informations internally, and so on. Or this form is jsut historical reasons, we follow the original patterns. I know the system catalogs is very important and critical to the DBMS. So pls don't mind me and my poor questions. TIA -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] question about the design consideration for system catalogs
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
