add server include files to default installation?

Fabien COELHO <coelho@cri.ensmp.fr> writes:

I wish to submit a small patch so that server includes and
all necessary configuration files could be installed *by default*.

There is a reason why install-all-headers is not the default. It is
that it shouldn't be the default: most people do not need it, because
they will never build any C extensions for themselves. It would just
be a waste of disk space for them.

If we did do such a thing it would have zero impact on the majority of
users anyway, because the RPM and other packagers will still put these
files into separate postgresql-devel packages, which would still not be
installed by default.

regards, tom lane

Fabien COELHO wrote:

Dear hackers,

I wish to submit a small patch so that server includes and
all necessary configuration files could be installed *by default*.

The current status is that server includes files are only installed
if explicitly required (make install-all-headers).

The idea is that external extension modules (new types or whatever)
could then *rely* on the fact that these files are available, which
would make developping and installing these extensions quite easier.

As an illustration, the apache software installs by default all
necessary includes and even a special tailored command (apxs) so as
to help extension modules to be compiled, installed and even configured
easilly.

Is there any opposition to this move? Silence will mean consent;-)

Agreed. I would also like to see Makefile.global installed.
pg_config.h has C-level configs, and Makefile.global has the
Makefile-level configs.

We have identified that we need to make configuration easier for 3rd
party apps.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Fabien COELHO wrote:

Dear hackers,

I wish to submit a small patch so that server includes and
all necessary configuration files could be installed *by default*.

The current status is that server includes files are only installed
if explicitly required (make install-all-headers).

The idea is that external extension modules (new types or whatever)
could then *rely* on the fact that these files are available, which
would make developping and installing these extensions quite easier.

As an illustration, the apache software installs by default all
necessary includes and even a special tailored command (apxs) so as
to help extension modules to be compiled, installed and even configured
easilly.

Is there any opposition to this move? Silence will mean consent;-)

Thanks in advance, have a nice day,

If the intention is that external extension types should be able to
build using the default installation you must also include the
src/Makefile.global and the src/Makefile.shlib. Cygwin ports are
dependent on the presence of src/utils/dllinit.c also (perhaps true for
win32 too). A dllinit.o would be sufficient of course.

Kind regards,

Thomas Hallgren

On Sat, 15 May 2004, Bruce Momjian wrote:

Fabien COELHO wrote:

Dear hackers,

I wish to submit a small patch so that server includes and
all necessary configuration files could be installed *by default*.

The current status is that server includes files are only installed
if explicitly required (make install-all-headers).

The idea is that external extension modules (new types or whatever)
could then *rely* on the fact that these files are available, which
would make developping and installing these extensions quite easier.

As an illustration, the apache software installs by default all
necessary includes and even a special tailored command (apxs) so as
to help extension modules to be compiled, installed and even configured
easilly.

Is there any opposition to this move? Silence will mean consent;-)

Agreed. I would also like to see Makefile.global installed.
pg_config.h has C-level configs, and Makefile.global has the
Makefile-level configs.

Don't agree with Makefile.global, cause then you have to also install the
physical template files for the various operating system too, no? What
else does Makefile.global rely on?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664

Marc G. Fournier wrote:

As an illustration, the apache software installs by default all
necessary includes and even a special tailored command (apxs) so as
to help extension modules to be compiled, installed and even configured
easilly.

Is there any opposition to this move? Silence will mean consent;-)

Agreed. I would also like to see Makefile.global installed.
pg_config.h has C-level configs, and Makefile.global has the
Makefile-level configs.

Don't agree with Makefile.global, cause then you have to also install the
physical template files for the various operating system too, no? What
else does Makefile.global rely on?

I think you would need the src/makefile files. The template files are
only used during configure. You might need some more include stuff too,
not sure. I see:

include $(top_builddir)/src/Makefile.port

and this gets confusing because Makefile.port is a symlink to the actual
file. I wonder if we could copy the actual file as Makefile.port. I
think that would work.

Anyway, I can also see packagers greping the Makefile for information.
For example, it is hard to know the thread flags except from the file.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Dear Tom,

I wish to submit a small patch so that server includes and
all necessary configuration files could be installed *by default*.

There is a reason why install-all-headers is not the default.

Sure. I hope so!

I'm questionning the pros and cons. I'm arguing that the cons against the
current situation are strong. Thanks for providing the pros, so it can be
discussed.

It is that it shouldn't be the default: most people do not need it,

How will people know that they will not need it afterwards?

As far as I'm concerned, I noticed it afterwards:-(
I'm a pretty stupid user, but I'm sure I'm not the only one.

For instance several weeks after installing a pg, I wanted to test
tsearch2 on one database. What do I need to do? Well, basically I need a
full recompile, or at least a full extract of the sources, re-configure
and compilation of the relevant contrib part. When reconfiguring, I need
to remember what options I used.

Now, as someone trying to develop extensions, I need to rely on some sound
and extendable default installation.

because they will never build any C extensions for themselves.

Hey, how do they know that before hand? They might need extensions. If
they need extensions, it is likely that they may have a C part. Most
contrib have a C part. External projects are likely to have a C part.
Some in user land (e.g. SPI_*), but not necessarilly.

Say aclitem accessor functions or new aggregates that may be needed for
some project that may be of interest to people. If there are not in, you
have to compile them. If the project cannot rely on the fact that
everything needed will be provided, it is no good.

It would just be a waste of disk space for them.

2MB... that is less than 0.002 EUR.

Moreover, I do not think that it is wasted, especially as postgresql is
moving things outside the main project (pgfoundry, contrib, gborg). You
must help external projects to live if you want them to leave;-)

As a compromise, we can have two makefile targets, say "install" and
"light-install".

I argue that the default should be the one which enable later extensions.

If we did do such a thing it would have zero impact on the majority of
users anyway, because the RPM and other packagers will still put these
files into separate postgresql-devel packages, which would still not be
installed by default.

Thanks for this argument! If packagers do it (I know of BSD ports) it mean
that they think it is useful. So it should be the default for people who
*bother* to install pg by hand, so that they don't have to do it twice
because they did not notice this installation subtlety.

IMHO, it is the core business of postgresql to help external projects by
providing a usable default infrastructure for them. As another example of
this bad behavior, having external projects (pgadmin or phppgadmin) to
"parse" aclitem descriptors because you want to keep things opaque and
they need it anyway is damaging.

Thanks for you answer, have a nice day,

--
Fabien Coelho - coelho@cri.ensmp.fr

Hi all,

Attached is a patch against HEAD implementing tablespaces.

I've done some testing on Linux and BSD. I've also compiled without
HAVE_SYMLINK defined -- which determines whether or not tablespaces are
available.

The reason for this is that symlinks are used extensively to simplify
access to relations in hairy places.

This is extensive discussion of this in the archives.

There are some outstanding TODOs. These include

pg_dump
documentation
regression tests
comment on

Chris KL has offered to tackle these.

Other outstanding things which need to be resolved:

XLog entries:

Within a tablespace, the files for different databases are isolated into
directories. Those directory names are the database oid for those files.
Since we create those files, we should log them. The question is, what is
the best way: appending it to an xlrec and storing its length in the xlrec
or adding another rdata with that in it?

The same goes for symlinks, where we need to store the oldpath and
newpath.

Alternative database location:

Should this code be removed now?

Drop tablespace:

I haven't added an interlock here (as suggested by Tom) to handle
situations where one transaction schedules the removal of a tablespace and
concurrently another transaction makes use of that tablespace. I'd
appreciate some advice on what this would look like: should a command
creating an object touch a CREATE a file and a DROP TABLESPACE block until
the file goes away, then check if it can drop the tablespace (ie, that the
tablespace is empty)? Likewise when DROP TABLESPACE proceeds, should it
block creates?

The other thing is handling DROP TABLESPACE in a transaction where the
tablespace has been emptied (using DROP TABLE, etc) during that
transaction. Because we only schedule the unlink() of the relation, the
data files will (and must) still be around. Is it reasonable to look
inside PendingRelDeletes to see if the tablespace will be empty at COMMIT?

Basic usage rundown

initdb sets up a new directory pg_tablespaces with some symlinks with in
it. To create a tablespace, you must first up create a tablespace
directory. Then you can create a tablespace inside postgres using:

CREATE TABLESPACE <name> LOCATION '/path/to/tbl/dir'

Then, the DDL commands can have a tablespace associatged with it:

CREATE DATABASE ... TABLESPACE <name>
CREATE SCHEMA ... TABLESPACE <name>
CREATE TABLE ... TABLESPACE <name>
CREATE INDEX ... TABLESPACE <name>
CREATE SEQUENCE ... TABLESPACE <name>

Comments, criticisms, etc, all welcome, of course.

Thanks,

Gavin

Dear hackers,

Agreed. I would also like to see Makefile.global installed.
pg_config.h has C-level configs, and Makefile.global has the
Makefile-level configs.

There is also "config.status" which is definitely of interest as it
allows to recreate the build tree, and which is not installed by default.

Independently of the actual file list to be included, where
could these makefiles be installed?

- share is for "architecture independent" files. Not really the case.

- include is rather for C files... but Makefile.global and others are
actually included, so it may make sense? If so, should it be directly
in the include/postgresql subdir, or some special subdir, say
"include/postgresql/config"?

- some other directory?

I would tend to put everything in "include/postgresql/config":
- Makefile.global
- a copy of Makefile.port (the actual file, not the link)
- config.status
- possibly other included files (NLS? win32? cygwin?)

Another issue is that Makefile.global seems hardwired to be in
the "src" subdirectory of a postgresql source tree, and to find other
files there:

# Pull in platform-specific magic
include $(top_builddir)/src/Makefile.port

This is an issue for external tools that would like to include
Makefile.global so as to be in the same environment as the server
compilation.

Any idea? The best I have would be to create a "src" subdir in the
installation, so that top_builddir could be set to
".../include/postgresql/config" and everything would work from that
point of view.

--
Fabien COELHO _ http://www.cri.ensmp.fr/~coelho _ Fabien.Coelho@ensmp.fr
CRI-ENSMP, 35, rue Saint-Honoré, 77305 Fontainebleau cedex, France
phone: (+33|0) 1 64 69 {voice: 48 52, fax: 47 09, standard: 47 08}
________ All opinions expressed here are mine _________

Gavin Sherry wrote:

Alternative database location:

Should this code be removed now?

Yes, I believe we agreed on this. One of the committers will take care
of that.

The only downside to removal is that folks without symlinks (I believe
Win32 only) will loose that functionality with nothing to replace it.
However, I think the clarity of removing it is worth it. Also, I think
someone had a special way to do symlinks on Win32 and we should look
into that.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Alternative database location:

Should this code be removed now?

Yes, I believe we agreed on this. One of the committers will
take care of that.

The only downside to removal is that folks without symlinks (I believe
Win32 only) will loose that functionality with nothing to replace it.
However, I think the clarity of removing it is worth it.
Also, I think someone had a special way to do symlinks on
Win32 and we should look into that.

If we're talking *directory symlinks only*, it can be done on Win32.
It's pretty ugly, the native UI doesn't support showing them etc, but it
can be done. (This is only Windows 2000+, not NT4, btw)

I still would like a non-symlink solution on Unix as well, but I've
noticed I'm with the minority side there, and this is still a lot better
than nothing...

//Magnus

I would tend to put everything in "include/postgresql/config":

On second thought, I would hesitate with "lib/...", as config file are
plateform specific so they cannot be shared with other plateforms,
although it could be the case for include files that they could be shared.

--
Fabien Coelho - coelho@cri.ensmp.fr

Bruce Momjian wrote:

The only downside to removal is that folks without symlinks (I believe
Win32 only) will loose that functionality with nothing to replace it.
However, I think the clarity of removing it is worth it. Also, I think
someone had a special way to do symlinks on Win32 and we should look
into that.

Windows 2000 and later support mount points - you can attach a new
partition as C:\pgsql\data\xlog instead of D:\. That might be enough for
most users. IIRC there was a tool to create arbitrary links, but it was
removed just before W2K final.

--
Manfred

"Manfred Spraul" <manfred@colorfullife.com> wrote in message
news:40A8EEE9.3000405@colorfullife.com...

Bruce Momjian wrote:

The only downside to removal is that folks without symlinks (I believe
Win32 only) will loose that functionality with nothing to replace it.
However, I think the clarity of removing it is worth it. Also, I think
someone had a special way to do symlinks on Win32 and we should look
into that.

Windows 2000 and later support mount points - you can attach a new
partition as C:\pgsql\data\xlog instead of D:\. That might be enough for
most users. IIRC there was a tool to create arbitrary links, but it was
removed just before W2K final.

If you run NTFS, it's still possible to use arbitrary links. In the Windows
world, they are called junctions. Microsoft does not provide a junction tool
for some reason (perhaps because it's limited to NTFS). A good tool, free
and with source, can be found here
http://www.sysinternals.com/ntw2k/source/misc.shtml#junction I use this tool
myself. Works like a charm.

Kind regards,

Thomas Hallgren

Thomas Hallgren wrote:

"Manfred Spraul" <manfred@colorfullife.com> wrote in message
news:40A8EEE9.3000405@colorfullife.com...

Bruce Momjian wrote:

The only downside to removal is that folks without symlinks (I believe
Win32 only) will loose that functionality with nothing to replace it.
However, I think the clarity of removing it is worth it. Also, I think
someone had a special way to do symlinks on Win32 and we should look
into that.

Windows 2000 and later support mount points - you can attach a new
partition as C:\pgsql\data\xlog instead of D:\. That might be enough for
most users. IIRC there was a tool to create arbitrary links, but it was
removed just before W2K final.

If you run NTFS, it's still possible to use arbitrary links. In the Windows
world, they are called junctions. Microsoft does not provide a junction tool
for some reason (perhaps because it's limited to NTFS). A good tool, free
and with source, can be found here
http://www.sysinternals.com/ntw2k/source/misc.shtml#junction I use this tool
myself. Works like a charm.

We've looked at it before. Apart from anything else I don't think its
license is compatible with PostgreSQL's.

Also, IIRC NTFS junctions also have some severe limitations.

cheers

andrew

The only downside to removal is that folks without symlinks

(I believe

Win32 only) will loose that functionality with nothing to

replace it.

However, I think the clarity of removing it is worth it.

Also, I think

someone had a special way to do symlinks on Win32 and we should look
into that.

Windows 2000 and later support mount points - you can attach a new
partition as C:\pgsql\data\xlog instead of D:\. That might

be enough for

most users. IIRC there was a tool to create arbitrary links,

but it was

removed just before W2K final.

If you run NTFS, it's still possible to use arbitrary links.

In the Windows

world, they are called junctions. Microsoft does not provide

a junction tool

for some reason (perhaps because it's limited to NTFS). A

good tool, free

and with source, can be found here
http://www.sysinternals.com/ntw2k/source/misc.shtml#junction

I use this tool

myself. Works like a charm.

We've looked at it before. Apart from anything else I don't think its
license is compatible with PostgreSQL's.

Well, people can still use it. We just can't distribute it... We can
always link to it.
But unless there is a GUI tool (actually, unless it shows up in the
*default* GUI tool), expect there to be questions. An

Also, IIRC NTFS junctions also have some severe limitations.

The main being they can't do files, and there are few tools for them.
Also, most win32 admins are *NOT* experienced with them. Sure, they are
used for the NETLOGON directory, but how many admins know that...

//Magnus

Magnus Hagander wrote:

If you run NTFS, it's still possible to use arbitrary links.

In the Windows

world, they are called junctions. Microsoft does not provide

a junction tool

for some reason (perhaps because it's limited to NTFS). A

good tool, free

and with source, can be found here
http://www.sysinternals.com/ntw2k/source/misc.shtml#junction

I use this tool

myself. Works like a charm.

We've looked at it before. Apart from anything else I don't think its
license is compatible with PostgreSQL's.

Well, people can still use it. We just can't distribute it... We can
always link to it.
But unless there is a GUI tool (actually, unless it shows up in the
*default* GUI tool), expect there to be questions. An

I assume we can just look at the source and write our own version
bypassing any license.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Alternative database location:

Should this code be removed now?

I think that this:

CREATE DATABASE blah LOCATION 'xyz';

Should now be interpreted to mean:

CREATE TABLESPACE blah_tbsp LOCATION 'xyz';
CREATE DATABSE blah TABLESPACE blah_tbsp;

Or something like that...

Chris

If you run NTFS, it's still possible to use arbitrary links. In the Windows
world, they are called junctions. Microsoft does not provide a junction tool
for some reason (perhaps because it's limited to NTFS). A good tool, free
and with source, can be found here
http://www.sysinternals.com/ntw2k/source/misc.shtml#junction

I use this tool myself. Works like a charm.

We've looked at it before. Apart from anything else I don't think its
license is compatible with PostgreSQL's.

The tool was suggested for use as is, not for inclusion in pg source.
It can be used to e.g. symlink xlog manually.

If you want something in pg source, the relevant lines (about 20)
can be copied from MSDN.

Andreas

Marc G. Fournier wrote:

On Sat, 15 May 2004, Bruce Momjian wrote:

Fabien COELHO wrote:

Dear hackers,

I wish to submit a small patch so that server includes and
all necessary configuration files could be installed *by default*.

The current status is that server includes files are only installed
if explicitly required (make install-all-headers).

The idea is that external extension modules (new types or whatever)
could then *rely* on the fact that these files are available, which
would make developping and installing these extensions quite easier.

As an illustration, the apache software installs by default all
necessary includes and even a special tailored command (apxs) so as
to help extension modules to be compiled, installed and even configured
easilly.

Is there any opposition to this move? Silence will mean consent;-)

Agreed. I would also like to see Makefile.global installed.
pg_config.h has C-level configs, and Makefile.global has the
Makefile-level configs.

Don't agree with Makefile.global, cause then you have to also install the
physical template files for the various operating system too, no? What
else does Makefile.global rely on?

Depending on the OS you also need funny things like mkldexport shell
scripts and the like. I thought we had a consensus of providing a
template build environment for external modules. This half-baked attempt
is not doing it. The makefiles make assumptions about their location
that aren't true any more when they're installed somewhere else.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

Dear Jan,

Depending on the OS you also need funny things like mkldexport shell
scripts and the like.

Possibly, yes... I don't know. I really need a list, then it is pretty
easy to update all makefiles.

I thought we had a consensus of providing a template build environment
for external modules.

Good! Where is it? I mean the template, not the consensus.

This half-baked attempt is not doing it. The makefiles make assumptions
about their location that aren't true any more when they're installed
somewhere else.

I noticed and took care of this point. In fact, it really depends on
top_builddir, so by setting this macro appropriately it should work.
Something like:

top_builddir := $(shell pg_config --insbuilddir)
include $(top_builddir)/src/Makefile.global

This mean that relevant files must be installed in subdirectories that are
named as the postgresql source tree... I agree that it is not beautiful,
but it seems to me that it is the simplest way to have contrib-like
makefiles outside of the main tree, and to be able to reuse the whole
infrastructure.

Obviously, any better idea is welcome, esp. if I do not have to do it
myself;-)

The current status is that *nothing* is provided, so I'm trying to have
something better than nothing with a reasonnable effort.

--
Fabien Coelho - coelho@cri.ensmp.fr

We've looked at it before. Apart from anything else I don't think
its license is compatible with PostgreSQL's.

Well, people can still use it. We just can't distribute

it... We can

always link to it.
But unless there is a GUI tool (actually, unless it shows up in the
*default* GUI tool), expect there to be questions. An

I assume we can just look at the source and write our own version
bypassing any license.

I wouldn't be so sure about that. If this insane SCO crap has
taught me anything, the PostgreSQL should have a defined and
legally vetted process for duplicating functionality. ala'
phoenix BIOS.

There is more than enough information om MSDN and other sites to make
this kind of tool without looking at the source. It's generic enough.

//Magnus

Magnus Hagander wrote:

If you run NTFS, it's still possible to use arbitrary links.

In the Windows

world, they are called junctions. Microsoft does not provide

a junction tool

for some reason (perhaps because it's limited to NTFS). A

good tool, free

and with source, can be found here
http://www.sysinternals.com/ntw2k/source/misc.shtml#junction

I use this tool

myself. Works like a charm.

We've looked at it before. Apart from anything else I don't think its
license is compatible with PostgreSQL's.

Well, people can still use it. We just can't distribute it... We can
always link to it.
But unless there is a GUI tool (actually, unless it shows up in the
*default* GUI tool), expect there to be questions. An

I assume we can just look at the source and write our own version
bypassing any license.

I wouldn't be so sure about that. If this insane SCO crap has taught me
anything, the PostgreSQL should have a defined and legally vetted process
for duplicating functionality. ala' phoenix BIOS.

What would be good is a "contaminated" developer specifying functionality,
and detailing the various APIs needed (documenting the undocumented ones
as nessisary) while someone else writes the code. It is the *only* legal
unemcumbered methodology that will work.

We've looked at it before. Apart from anything else I don't think
its license is compatible with PostgreSQL's.

Well, people can still use it. We just can't distribute

it... We can

always link to it.
But unless there is a GUI tool (actually, unless it shows up in the
*default* GUI tool), expect there to be questions. An

I assume we can just look at the source and write our own version
bypassing any license.

I wouldn't be so sure about that. If this insane SCO crap has
taught me anything, the PostgreSQL should have a defined and
legally vetted process for duplicating functionality. ala'
phoenix BIOS.

There is more than enough information om MSDN and other sites to make
this kind of tool without looking at the source. It's generic enough.

Let's just make sure we keep records of the generic sources of where we
find things. I get *really* scared when I see sentences like "I assume we
can just look at the source and write our own version bypassing any
license." That is categorically a false asumption and will create an
arguably derived product. The last thing we want is Oracle or Microsoft
trying to pull an SCO on Postgresql.

pgsql@mohawksoft.com wrote:

We've looked at it before. Apart from anything else I don't think
its license is compatible with PostgreSQL's.

Well, people can still use it. We just can't distribute

it... We can

always link to it.
But unless there is a GUI tool (actually, unless it shows up in the
*default* GUI tool), expect there to be questions. An

I assume we can just look at the source and write our own version
bypassing any license.

I wouldn't be so sure about that. If this insane SCO crap has
taught me anything, the PostgreSQL should have a defined and
legally vetted process for duplicating functionality. ala'
phoenix BIOS.

There is more than enough information om MSDN and other sites to make
this kind of tool without looking at the source. It's generic enough.

Let's just make sure we keep records of the generic sources of where we
find things. I get *really* scared when I see sentences like "I assume we
can just look at the source and write our own version bypassing any
license." That is categorically a false asumption and will create an
arguably derived product. The last thing we want is Oracle or Microsoft
trying to pull an SCO on Postgresql.

Usually we look at the source, find out how they do it, then find the
docs for the underlying functions, and use that.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

pgsql@mohawksoft.com wrote:

Let's just make sure we keep records of the generic sources of where we
find things. I get *really* scared when I see sentences like "I assume
we
can just look at the source and write our own version bypassing any
license." That is categorically a false asumption and will create an
arguably derived product. The last thing we want is Oracle or Microsoft
trying to pull an SCO on Postgresql.

Usually we look at the source, find out how they do it, then find the
docs for the underlying functions, and use that.

This makes me worried. That's the way we *used* to do things, but the
sleazy IP lawyers are looking for anything with which they can create the
impression of impropriety. The open source and free projects are ground
zero for this crap.

We *really* need to be careful.

I assumed this tool was GPL and we just needed to avoid the GPL issue.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

pgsql@mohawksoft.com wrote:

We've looked at it before. Apart from anything else I don't think
its license is compatible with PostgreSQL's.

Well, people can still use it. We just can't distribute

it... We can

always link to it.
But unless there is a GUI tool (actually, unless it shows up in

the

*default* GUI tool), expect there to be questions. An

I assume we can just look at the source and write our own version
bypassing any license.

I wouldn't be so sure about that. If this insane SCO crap has
taught me anything, the PostgreSQL should have a defined and
legally vetted process for duplicating functionality. ala'
phoenix BIOS.

There is more than enough information om MSDN and other sites to make
this kind of tool without looking at the source. It's generic enough.

Let's just make sure we keep records of the generic sources of where we
find things. I get *really* scared when I see sentences like "I assume
we
can just look at the source and write our own version bypassing any
license." That is categorically a false asumption and will create an
arguably derived product. The last thing we want is Oracle or Microsoft
trying to pull an SCO on Postgresql.

Usually we look at the source, find out how they do it, then find the
docs for the underlying functions, and use that.

This makes me worried. That's the way we *used* to do things, but the
sleazy IP lawyers are looking for anything with which they can create the
impression of impropriety. The open source and free projects are ground
zero for this crap.

We *really* need to be careful.

pgsql@mohawksoft.com wrote:

This makes me worried. That's the way we *used* to do things, but the
sleazy IP lawyers are looking for anything with which they can create
the
impression of impropriety. The open source and free projects are ground
zero for this crap.

We *really* need to be careful.

I assumed this tool was GPL and we just needed to avoid the GPL issue.

I'm probably just being alarmist, but think about some IP lawyer buying up
the entity that owns the GPL code, and suing end user's of PostgreSQL.

This is similar to what is happening in Linux land with SCO.

The best defense is to say, nope, we didn't copy your stuff, we
implemented it ourselves based on the documentation.

Fabien COELHO wrote:

Any idea? The best I have would be to create a "src" subdir in the
installation, so that top_builddir could be set to
".../include/postgresql/config" and everything would work from that
point of view.

This is from an extension module author's point of view. My module will
reference these two files only:

Makefile.global
Makefile.shlib

I'm not the least interested in how these files are organized internally
or where they are placed in reference to what they contain. I don't care
where the include files, config files, or other files are located, as
long as these two files will set my flags accordingly. I think it's
important to recognize this separation of concern. Extension modules
should not need to worry about anything but where to find these two files.

If I have a "pg_config --makefiledir" that tells me where to find the
files, that should be all I need:

makefiledir := $(shell pg_config --makefiledir)
include $(makefiledir)/Makefile.global
...
include $(makefiledir)/Makefile.shlib

If I go in and parse the makefiles to dig out information or do
something equally horrible, I'm either doing something wrong or
something is missing in the "contract" between the backend and the
extension module and should be rectified there. The contract, the way I
see it, is constituted by the two files.

Just trying to give you a bit more freedom to place your files :-)

Kind regards,

Thomas Hallgren

This is from an extension module author's point of view. My module will
reference these two files only:

Makefile.global
Makefile.shlib

These files possibly include other makefiles.

I'm not the least interested in how these files are organized internally

Sure.

If I have a "pg_config --makefiledir" that tells me where to find the
files, that should be all I need:

makefiledir := $(shell pg_config --makefiledir)
include $(makefiledir)/Makefile.global
...
Just trying to give you a bit more freedom to place your files :-)

You do not understand how bad it is from the inside;-)
In the current Makefile.global, you find things like:

include $(top_...)/src/Makefile.port

That is the makefile knows where it is expected to reside wrt the source
tree, and use this information. In order to allow what you describe, I
would have to fix this issue, that is rewrite somehow Makefile.global and
other makefiles. Maybe I could do that, but I was trying hard to avoid
it, as there may be some kind of portability issues.

Thanks for you comment,

--
Fabien Coelho - coelho@cri.ensmp.fr

On Wednesday 19 May 2004 00:19, pgsql@mohawksoft.com wrote:

pgsql@mohawksoft.com wrote:

This makes me worried. That's the way we *used* to do things, but the
sleazy IP lawyers are looking for anything with which they can create
the
impression of impropriety. The open source and free projects are ground
zero for this crap.

We *really* need to be careful.

I assumed this tool was GPL and we just needed to avoid the GPL issue.

I'm probably just being alarmist, but think about some IP lawyer buying up
the entity that owns the GPL code, and suing end user's of PostgreSQL.

This is similar to what is happening in Linux land with SCO.

The best defense is to say, nope, we didn't copy your stuff, we
implemented it ourselves based on the documentation.

by that argument, the license of documentation should matter too.. Isn't it?

Shridhar

On Wednesday 19 May 2004 00:19, pgsql@mohawksoft.com wrote:

pgsql@mohawksoft.com wrote:

This makes me worried. That's the way we *used* to do things, but the
sleazy IP lawyers are looking for anything with which they can create
the
impression of impropriety. The open source and free projects are

ground

zero for this crap.

We *really* need to be careful.

I assumed this tool was GPL and we just needed to avoid the GPL issue.

I'm probably just being alarmist, but think about some IP lawyer buying
up
the entity that owns the GPL code, and suing end user's of PostgreSQL.

This is similar to what is happening in Linux land with SCO.

The best defense is to say, nope, we didn't copy your stuff, we
implemented it ourselves based on the documentation.

by that argument, the license of documentation should matter too.. Isn't
it?

If the documentation is "proprietary and confidential" then maybe, but if
it is publically available and its purpose is to show you various
techniques, then probably not.

I'm not a lawyer, but I have had to be sensitive to some of these issues.
One of SCO's strategies is to liken source code with music. Arguing that
it is "like ours" so it is derivitive. I'm not sure if that will fly in
court, but it has worked in music suits.

All I'm saying is we should all be mindfull of the various IP law
land-mines currently planted in our industry.

I have a fairly good understanding of how the Makefile.global etc. is
organized. My point is, in order to maintain a good separation of concern, I
should not use this knowledge.

IMHO, there's a need for a well documented "module extension build API"
accessible from a well known place. This is more important than to include
it in the default installation. Once in place it will lessen the
dependencies between the server installation and the extension modules. The
PostgreSQL core can then change the make structure, directory layout, etc.
without affecting the extension modules that uses the build API. If they
don't use it, any incompatibility is their responsability.

Your suggestion to rewrite the Makefile.global etc. is a good first step.

Kind regards,

Thomas Hallgren

Dear Thomas,

My point is, in order to maintain a good separation of concern, I
should not use this knowledge.

I agree.

IMHO, there's a need for a well documented "module extension build API"
accessible from a well known place.

Sure.

I'm not really addressing that at the moment, I'm addressing having the
necessary files. Given gnu-make constraints about makefile inclusions,
that requires to have the same layout as the initial source tree, whatever
it is. I'm not sure that dropping all includes would be an easy move, nor
even desirable.

This is more important than to include it in the default installation.

Well, the point of having an infrastructure if extensions cannot rely it
being there when needed is not clear to me.

Your suggestion to rewrite the Makefile.global etc. is a good first step.

It is what I'm trying to avoid;-) It is not just this makefile, but the
whole include-based makefiles that are at stake. I think that an
infrastructure is possible without fixing these files.

So as I understand your point as "the layout constraints should not be
visible from the extensions API", I suggest that extension makefiles
should look like (adapted from contrib):

PGXSDIR := $(shell pg_config --pgxs-dir)
include $(PGXSDIR)/pgxs_begin.mk
[... set required macros as in contrib ...]
include $(PGXSDIR)/pgxs_end.mk

It is independent from what my first patch addresses, that is
tryinbg to put all required files somewhere on install.

Thanks for your point,

--
Fabien Coelho - coelho@cri.ensmp.fr

pgsql@mohawksoft.com wrote:

On Wednesday 19 May 2004 00:19, pgsql@mohawksoft.com wrote:

pgsql@mohawksoft.com wrote:

This makes me worried. That's the way we *used* to do things, but the
sleazy IP lawyers are looking for anything with which they can create
the
impression of impropriety. The open source and free projects are

ground

zero for this crap.

We *really* need to be careful.

I assumed this tool was GPL and we just needed to avoid the GPL issue.

I'm probably just being alarmist, but think about some IP lawyer buying
up
the entity that owns the GPL code, and suing end user's of PostgreSQL.

This is similar to what is happening in Linux land with SCO.

The best defense is to say, nope, we didn't copy your stuff, we
implemented it ourselves based on the documentation.

The safe bet if we want to use junction points is to use clean room
techniques. I understand from other comments that it wouldn't be difficult.

cheers

andrew

pgsql@mohawksoft.com wrote:

I'm probably just being alarmist, but think about some IP lawyer buying up
the entity that owns the GPL code, and suing end user's of PostgreSQL.

You cannot retrospectively change the terms of a license unless the
licensee agrees to it. If something is released GPL, then the GPL
applies to that code and subsequent derivatives - that's the point of
the GPL.

The new "owner" may change the terms of a license for new distributions
of a package, assuming they actually own all the IP, and this is what I
understand is the SCO issue. SCO claim that code that was distributed
was done so without permission.

For an opposite effect, see the origins of the OpenSSH project; to
summarise, folks found than an older version of a (at that time) vaguely
licensed ssh was BSD licensed ans it was used as a base for a new
product - namely OpenSSH.

rgds,
--
Peter

Peter Galbavy wrote:

pgsql@mohawksoft.com wrote:

I'm probably just being alarmist, but think about some IP lawyer
buying up
the entity that owns the GPL code, and suing end user's of PostgreSQL.

You cannot retrospectively change the terms of a license unless the
licensee agrees to it. If something is released GPL, then the GPL
applies to that code and subsequent derivatives - that's the point of
the GPL.

The new "owner" may change the terms of a license for new
distributions of a package, assuming they actually own all the IP, and
this is what I understand is the SCO issue. SCO claim that code that
was distributed was done so without permission.

For an opposite effect, see the origins of the OpenSSH project; to
summarise, folks found than an older version of a (at that time)
vaguely licensed ssh was BSD licensed ans it was used as a base for a
new product - namely OpenSSH.

The code in question is not covered by the GPL, IIRC, which makes this
somewhat moot. The README that comes with it says:

Terms of Use
------------

This software is provided "as is", without any guarantee made
as to its suitability or fitness for any particular use. It may
contain bugs, so use of this tool is at your own risk. We take
no responsilbity for any damage that may unintentionally be caused
through its use.

You may not distribute this tool without the express written
permission of Mark Russinovich.

cheers

andrew

pgsql@mohawksoft.com wrote:

I'm probably just being alarmist, but think about some IP lawyer buying
up
the entity that owns the GPL code, and suing end user's of PostgreSQL.

You cannot retrospectively change the terms of a license unless the
licensee agrees to it. If something is released GPL, then the GPL
applies to that code and subsequent derivatives - that's the point of
the GPL.

The new "owner" may change the terms of a license for new distributions
of a package, assuming they actually own all the IP, and this is what I
understand is the SCO issue. SCO claim that code that was distributed
was done so without permission.

Imagine this scenario:

OpenFoobar is released as GPL. Portions of his code are found in
PostgreSQL. The new owner of OpenFoobar is an IP lawyer. They claim
ownership of code "derived" from "his" code. There is now a valid, or at
least legally arguable, argument that PostgreSQL now demands GPL source
availability.

I use PostgreSQL as a database foundation or my search-engine. Much of my
system is open source, but there are portions which are not. If the IP
lawyer is a competitor, he can force me to release my code.

We do not want to open up the BSD vs GPL debate, but keeping PG as a BSD
license does take an amount of accounting.

Peter Galbavy wrote:

pgsql@mohawksoft.com wrote:

I'm probably just being alarmist, but think about some IP lawyer
buying up
the entity that owns the GPL code, and suing end user's of PostgreSQL.

You cannot retrospectively change the terms of a license unless the
licensee agrees to it. If something is released GPL, then the GPL
applies to that code and subsequent derivatives - that's the point of
the GPL.

The new "owner" may change the terms of a license for new
distributions of a package, assuming they actually own all the IP, and
this is what I understand is the SCO issue. SCO claim that code that
was distributed was done so without permission.

For an opposite effect, see the origins of the OpenSSH project; to
summarise, folks found than an older version of a (at that time)
vaguely licensed ssh was BSD licensed ans it was used as a base for a
new product - namely OpenSSH.

The code in question is not covered by the GPL, IIRC, which makes this
somewhat moot. The README that comes with it says:

Terms of Use
------------

This software is provided "as is", without any guarantee made
as to its suitability or fitness for any particular use. It may
contain bugs, so use of this tool is at your own risk. We take
no responsilbity for any damage that may unintentionally be caused
through its use.

You may not distribute this tool without the express written
permission of Mark Russinovich.

Then by no means should *any* of that code be included into PostgreSQL. In
fact, comments should not even make reference to it.

pgsql@mohawksoft.com wrote:

Imagine this scenario:

OpenFoobar is released as GPL. Portions of his code are found in
PostgreSQL. The new owner of OpenFoobar is an IP lawyer. They claim
ownership of code "derived" from "his" code. There is now a valid, or
at least legally arguable, argument that PostgreSQL now demands GPL
source availability.

I use PostgreSQL as a database foundation or my search-engine. Much of
my system is open source, but there are portions which are not. If the
IP lawyer is a competitor, he can force me to release my code.

This is a common misconception. It ain't so. According to Eblen Moglen:

"The claim that a GPL violation could lead to the forcing open of
proprietary code that has wrongfully included GPL'd components is simply
wrong. There is no provision in the Copyright Act to require distribution
of infringing work on altered terms. What copyright plaintiffs are
entitled to, under the Act, are damages, injunctions to prevent infringing
distribution, and--where appropriate--attorneys' fees. A defendant found
to have wrongfully included GPL'd code in its own proprietary work can be
mulcted in damages for the distribution that has already occurred, and
prevented from distributing its product further. That's a sufficient
disincentive to make wrongful use of GPL'd program code. And it is all
that the Copyright Act permits."

I have mixed feelings about the GPL myself, but I hate seeing this FUD so
frequently.

In any case, the whole thing that kicked off this discussion is *not* GPL
software. So let's get on with our business.

cheers

andrew

Andrew Dunstan wrote:

This is a common misconception. It ain't so. According to Eblen Moglen:

"The claim that a GPL violation could lead to the forcing open of
proprietary code that has wrongfully included GPL'd components is simply
wrong. There is no provision in the Copyright Act to require distribution
of infringing work on altered terms. What copyright plaintiffs are
entitled to, under the Act, are damages, injunctions to prevent infringing
distribution, and--where appropriate--attorneys' fees. A defendant found
to have wrongfully included GPL'd code in its own proprietary work can be
mulcted in damages for the distribution that has already occurred, and
prevented from distributing its product further. That's a sufficient
disincentive to make wrongful use of GPL'd program code. And it is all
that the Copyright Act permits."

I have mixed feelings about the GPL myself, but I hate seeing this FUD so
frequently.

In any case, the whole thing that kicked off this discussion is *not* GPL
software. So let's get on with our business.

Of course, but the FSF has agreed to drop litigation in some cases if
the proprietary software is released as open source. He is right that
that moving to GPL isn't a legal remedy, but more of a negotiated
settlement. So that is why that idea gets thrown around, so I wouldn't
call it totally FUD.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

How much can we count on the type oid's remaining static from version to
version? It turns out there is a design decision in the jdbc driver that
could fail if they changed from one version to another and the client
connected to both versions.

Also for getUDT, we need to translate type oid's into java type values,
so if we can rely on the oids not changing then it would make it easier.

--
Dave Cramer
519 939 0336
ICQ # 14675561

Dave Cramer wrote:

How much can we count on the type oid's remaining static from version to
version? It turns out there is a design decision in the jdbc driver that
could fail if they changed from one version to another and the client
connected to both versions.

I don't think we have ever changed oids for existing data types, so you
should be OK.

Also for getUDT, we need to translate type oid's into java type values,
so if we can rely on the oids not changing then it would make it easier.

Right. There has never been a reason to change them, and there is a
downside if we were to change them.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

You may not distribute this tool without the express written
permission of Mark Russinovich.

Then by no means should *any* of that code be included into PostgreSQL. In
fact, comments should not even make reference to it.

May I point out that there is a heap of debate about whether or not we
can use a windows API call legally (yes we can), and a big lump of
not-testing-tablespaces patch going on :)

Chris

I don't think we have ever changed oids for existing data types, so you
should be OK.

Are you sure? If we remove a type, then its oid becomes up for grabs by
the unused_oids script.

We have removed a few functions in 7.4 (oidsrand, etc.) and I wouldn't
be surprised if we haven't _already_ reused those oids...

I think the core should mandate it as policy never to reuse oids and
perhaps make the unused_oids script "remember" what has been used...

Chris

pgsql@mohawksoft.com wrote:

Peter Galbavy wrote:

You may not distribute this tool without the express written
permission of Mark Russinovich.

Then by no means should *any* of that code be included into PostgreSQL. In
fact, comments should not even make reference to it.

Does anybody have that "written permission" to include this code into
PostgreSQL and redistribute it under the BSD license? If not, the code
has to be rejected at this moment.

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #

Christopher Kings-Lynne wrote:

I don't think we have ever changed oids for existing data types, so you
should be OK.

Are you sure? If we remove a type, then its oid becomes up for grabs by
the unused_oids script.

True, but have we ever removed types? I can't think of one.

We have removed a few functions in 7.4 (oidsrand, etc.) and I wouldn't
be surprised if we haven't _already_ reused those oids...

Yes, for functions that is very true.

I think the core should mandate it as policy never to reuse oids and
perhaps make the unused_oids script "remember" what has been used...

Oh, yea, we could do that. In fact, we are only use 25% of available
system oids (from unused_oids):

2546 - 9999

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

True, but have we ever removed types? I can't think of one.

Hmmm...perhaps.

We have removed a few functions in 7.4 (oidsrand, etc.) and I wouldn't
be surprised if we haven't _already_ reused those oids...

Yes, for functions that is very true.

I wonder if that has any implications for future binary upgrade tools...

Chris

Christopher Kings-Lynne wrote:

True, but have we ever removed types? I can't think of one.

Hmmm...perhaps.

We have removed a few functions in 7.4 (oidsrand, etc.) and I wouldn't
be surprised if we haven't _already_ reused those oids...

Yes, for functions that is very true.

I wonder if that has any implications for future binary upgrade tools...

I don't think so because we use the new system catalogs for upgrades and
just move the user data.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

On Thu, 20 May 2004, Christopher Kings-Lynne wrote:

You may not distribute this tool without the express written
permission of Mark Russinovich.

Then by no means should *any* of that code be included into PostgreSQL. In
fact, comments should not even make reference to it.

May I point out that there is a heap of debate about whether or not we
can use a windows API call legally (yes we can), and a big lump of
not-testing-tablespaces patch going on :)

Attached is a more recent version with fixes for some memory errors as
well as additional functionality, such as the ability to create
tablespaces with owners other than a superuser.

Thanks,

Gavin

Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:

I don't think we have ever changed oids for existing data types, so you
should be OK.

Are you sure? If we remove a type, then its oid becomes up for grabs by
the unused_oids script.

But if we remove a type then it's a bit moot whether the OID for it
stays constant. For types that have remained present across all
versions I don't think we have ever changed the OID assignment.
I'd be willing to promise that this will stay true for the types
that are "manually" declared in pg_type.h. (As a counterexample,
I think that information_schema.sql creates some domain types, and
those types aren't going to have frozen OIDs.)

I think the core should mandate it as policy never to reuse oids and
perhaps make the unused_oids script "remember" what has been used...

Absolutely not worth the trouble. If we were to guarantee not to remove
types, then there might be some value in making such a promise, but we
haven't and won't. (Precedent: the SQL spec itself has added and
dropped datatypes.)

regards, tom lane

You may not distribute this tool without the express written
permission of Mark Russinovich.

Then by no means should *any* of that code be included into PostgreSQL.
In
fact, comments should not even make reference to it.

May I point out that there is a heap of debate about whether or not we
can use a windows API call legally (yes we can), and a big lump of
not-testing-tablespaces patch going on :)

You can use Windows API calls on Windows just fine. Any debate about that
would be focused on running PostgreSQL (compiled for Windows) under wine,
on some other platform, and that would be focused on the Wine project.

More to the point. If you designed a feature of PostgreSQL for Windows,
and kept the Windows API call and syntax, but coded it for Linux and BSD
using the Windows API, then you may be violating copyright.

Fabien COELHO wrote:

Dear Thomas,

My point is, in order to maintain a good separation of concern, I
should not use this knowledge.

I agree.

IMHO, there's a need for a well documented "module extension build API"
accessible from a well known place.

Sure.

I'm not really addressing that at the moment, I'm addressing having the
necessary files. Given gnu-make constraints about makefile inclusions,
that requires to have the same layout as the initial source tree, whatever
it is. I'm not sure that dropping all includes would be an easy move, nor
even desirable.

This is more important than to include it in the default installation.

Well, the point of having an infrastructure if extensions cannot rely it
being there when needed is not clear to me.

Agreed. If we are pushing things out, it seems it is our duty to make
it easy for outside things to integrate and build properly.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Fabien COELHO wrote:

Well, the point of having an infrastructure if extensions cannot rely it
being there when needed is not clear to me.

Agreed. If we are pushing things out, it seems it is our duty to make
it easy for outside things to integrate and build properly.

It does not thereby follow that we should try to merge devel and base
packages (to express it in RPM terms). Compiling extension packages is
not and probably never will be something that the average user does,
and there's no reason to burden him with the disk footprint to support
something he's not gonna do.

We do need to work out what our story is for compiling extensions
without the original source/build trees. But the needed files should
be an install option, not the default.

regards, tom lane

pgsql@mohawksoft.com wrote:

Imagine this scenario:

OpenFoobar is released as GPL. Portions of his code are found in
PostgreSQL. The new owner of OpenFoobar is an IP lawyer. They claim
ownership of code "derived" from "his" code. There is now a valid, or
at least legally arguable, argument that PostgreSQL now demands GPL
source availability.

I use PostgreSQL as a database foundation or my search-engine. Much of
my system is open source, but there are portions which are not. If the
IP lawyer is a competitor, he can force me to release my code.

This is a common misconception. It ain't so. According to Eblen Moglen:

"The claim that a GPL violation could lead to the forcing open of
proprietary code that has wrongfully included GPL'd components is simply
wrong. There is no provision in the Copyright Act to require distribution
of infringing work on altered terms. What copyright plaintiffs are
entitled to, under the Act, are damages, injunctions to prevent infringing
distribution, and--where appropriate--attorneys' fees. A defendant found
to have wrongfully included GPL'd code in its own proprietary work can be
mulcted in damages for the distribution that has already occurred, and
prevented from distributing its product further. That's a sufficient
disincentive to make wrongful use of GPL'd program code. And it is all
that the Copyright Act permits."

I have mixed feelings about the GPL myself, but I hate seeing this FUD so
frequently.

This isn't FUD, I release GPL code. Maybe I detailed a specific
"conclusion" instead of a process. One of the obvious remedies for GPL
"damages" would be to open the code.

In any case, the whole thing that kicked off this discussion is *not* GPL
software. So let's get on with our business.

Agreed, but, PostgreSQL is a great product/project, it has the ability to
challenge *big* database companies, and *big* companies have blood sucking
IP lawyers. A little care and attention now will pay down the road.

pgsql@mohawksoft.com wrote:

We do not want to open up the BSD vs GPL debate, but keeping PG as a BSD
license does take an amount of accounting.

I was using GPL as an example, as it was mentioned earlier in the
thread. My comments hold for *any* license, including (at least in the
UK; unfair contracts legislation) licenses that say that they can be
changed by the licensor at a later time without agreement of the licensee.

Peter

Dear Tom,

Agreed. If we are pushing things out, it seems it is our duty to make
it easy for outside things to integrate and build properly.

It does not thereby follow that we should try to merge devel and base
packages (to express it in RPM terms).

They are not necessarily merged, and it is quite easy to separate them
from the rpm maintainer point of view if s?he desire to do so. This is
already done for apache for instance, as the default installation includes
all build utilities. There is no problem separate build utils, or even to
make it easier than it is already if you want.

Compiling extension packages is not and probably never will be something
that the average user does, and there's no reason to burden him with the
disk footprint to support something he's not gonna do.

We're arguing about the public which does compile postgresql. Guys or
girls that downloaded the source, configure and so. That is not the
average user indeed, but occasional sysadmins like me, and I like my life
to be easier. I'm ready to pay 0.002 EUR of disk space for that,
especially as the 0.002 EUR (about $0.002 for you) are those of my
employer;-)

We can discuss whether that price is too high for the average sysadmin,
but at the cost of my time and yours, I think we spent quite a lot of
money arguing about this issue that would pay for all the disk space in
the world that is needed;-)

We do need to work out what our story is for compiling extensions
without the original source/build trees.

We agree;-) I've made suggestions and send a "proof of concept patch"
which is waiting for your comments and better ideas. I'm not sure it is
the best ever possible way to allow extensions, but it works and it is
reasonnable enough IMHO, so it is at least a base for discussion.

But the needed files should be an install option, not the default.

The previous point can be solved independetly of this issue, as you
pointed out. Let's begin with that.

--
Fabien Coelho - coelho@cri.ensmp.fr