Re: [HACKERS] Data type removal

From: The Hermit Hacker <scrappy(at)hub(dot)org>
To: Darren King <darrenk(at)insightdist(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Data type removal
Date: 1998-03-24 16:51:55
Message-ID: Pine.NEB.3.95.980324114907.26269K-100000@hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 24 Mar 1998, Darren King wrote:

> > > How about this as a compromise. We make these packages available in
> > > the contrib or other such area as loadable modules as well as making
> > > them available right in the main backend code, but setup configure
> > > options to enable/disable them, so when I compile, I can say
> > > "--without-geometry" to compile without those types and functions. If I
> > > want to add them back in later, I can compile the loadable module
> > > version and add them in.
> >
> > As I stated earlier, if someone wants to add a
> > '--without-geometry' option to configure that removes it, I have no problem
> > with that...but it will only be to remove the feature, not add it in.
>
> I can live with this. Everything is "--with-xxx" by default, but can not
> be built in by using "--without-xxx".
>
> Would it be acceptable to move the code for these to a new directory, say,
> src/modules? Something along the lines of...
>
> src/modules/geometric
> src/modules/ip_and_mac
>
> This would allow for each type to have a pg_proc.h, pg_type.h, etc. Much
> cleaner than #define'ing the heck out of the existing include files. The
> geometric/pg_proc.h would contain the entries from pg_proc.h. Then there
> would also be a .sql file that contains the necessary commands to load
> the module if it was not compiled in or was just needed in one database.
>
> Forcing someone to re-compile to use module would seem to go completely
> against the extensibility side of postgres.
>
> I think once there is one thing there as a module, it will serve as an
> example for others. A simple example would be the cash/money code. Add
> an indexing method to it and it would be a brief but complete example.

Why don't we start with the ip_and_mac stuff...take that,
integrate it into the "core", build it so that --without-ip_and_mac
disables it, and let's see how that one works.

What I'm curious about right now is what different its going to
make. Does having ip_and_mac in the core, even if I don't use it, reduce
performance, or makes no difference? How much does it increase the
footprint of the binary? If it makes negligble difference, then it isn't
worth doing, you may as well just leave everything in there...

But, build us a sample with the ip_and_mac stuff, as to what you
are thinking and let's go from that...but ignore the *core* stuff for
now...

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Maarten Boekhold 1998-03-24 17:02:46 Re: [HACKERS] char types gone.
Previous Message The Hermit Hacker 1998-03-24 16:38:54 Re: [HACKERS] char types gone.