From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Everything is now "required by the database system" |
Date: | 2002-08-13 17:24:46 |
Message-ID: | 1029259486.4744.44.camel@rh72.home.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, 2002-08-13 at 22:38, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > With the new dependency system we have the entire system catalog content
> > pinned down and unchangeable. This is a tiny dent in the nice extensible
> > nature of the system.
>
> It's still "extensible", it's just not so easily "contractible"...
>
> I'm not sure that this matters, as I've never heard of anyone actually
> troubling to remove unused datatypes etc.
It could become an issue if PostgreSQL became populat in embedded
systems, but then it can of course be done in include/catalog/.
> > Would it be feasible to identify the non-essential parts of the built-in
> > objects (say, inet type, numeric type, associated functions, etc.) and
> > declare those with regular SQL commands in initdb? In the end, the system
> > catalog contents in include/catalog/ would only contain the "bootstrap"
> > content. For example, the pg_proc content could be made more manageable
> > that way.
>
> No, it would become a lot less manageable because we'd have a harder
> time controlling OIDs for builtin types and functions.
We have COPY ... WITH OIDS for some time already.
Maybe we should also allow setting OID in INSERT and UPDATE ?
It could be a good idea to give out OID ranges for contrib modules so
that frontends would not need to worry about changing binary formats for
same types.
That could also suggest that the new int8-based datetime type should
have a separate OID from the old one.
> We'd end up
> having to push everything we deemed inessential out to non-builtin
> status (compare the contrib items that create new types). While there's
> some stuff like money and the geometric types
It would be nice if for example GEOMETRY could be a separate installable
package (a datablade in Illustra parlance).
IP types (cidr, macadr) are also a good candidate for non-builtin type
money type could be a package by its own ;)
> that maybe deserve such
> demotion, there's not enough to get me excited about trimming it.
> While reviewing the pg_depend patch I was hoping that we could pin just
> a subset of the initial catalog contents, but eventually decided it was
> (a) tricky
True
> (b) not worth the trouble.
But it could still be something to watch out for doing in the future.
Of course we will have then package dependency issues, but most likely
at least the GEOMETRY,IP and MONEY packages don't need each other.
There are also two kinds of builtins - things that are almost
exclusively used by system (smgr, oidvector, int2vector, tid, xid, cid,
regproc, refcursor, aclitem, name) and basic types of general utility
(int, date, text, ...)
Probably every type not used in system tables themselves could be made
loadable after initdb.
-----------------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2002-08-13 17:28:18 | Re: OOP real life example (was Re: Why is MySQL more |
Previous Message | Tom Lane | 2002-08-13 17:23:53 | Re: libpqxx |