From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "Magnus Hagander" <magnus(at)hagander(dot)net>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_proc without oid? |
Date: | 2007-02-19 16:08:05 |
Message-ID: | 87zm7anna2.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> In the second place, if you don't want to predetermine OIDs for your
> functions then they shouldn't be in hardwired pg_proc.h rows at all.
Is there any place to hook in to create things like procedures or other SQL
objects that don't really need hard coded OIDs?
It seems like we could make the catalogs much easier to maintain by ripping
out everything that isn't needed by the system tables themselves and having
initdb create them by running a plain SQL script.
In particular I'm looking towards having all the operators and associated
hardware except for the basic btree operators for types used by the system
tables be created in plain SQL.
It might also reduce the pain OID conflicts cause.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2007-02-19 16:10:36 | Re: Multiple Storage per Tablespace, or Volumes |
Previous Message | Guillaume Smet | 2007-02-19 15:54:26 | Re: n-gram search function |