Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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

In response to

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group