On Wed, Apr 21, 2004 at 11:47:11PM -0300, Marc G. Fournier wrote:
On Wed, 21 Apr 2004, Joe Conway wrote:
- dblink-type capability should someday make it into the backend, albeit
in the form of something compliant to the SQL/MED spec. This is
standard functionality in many of the
I wrote earlier:
alvherre=# commit;
ERROR: cannot drop active portal
This happens while PortalDrop() tries to drop an active portal. In this
state, I can't do anything else short of closing the connection. But
this doesn't happen if I try to run a non-utility bogus statement
(SELECT
Rod Taylor wrote:
I think most of the current contrib projects are more missing the
advantage version independence would have for the ease of sitting in
contrib and having the whole project management around them just done.
Yes, doing your own gborg project costs time. You have to maintain
Hello,
I believe that one problem with the contrib is that in order to build
most of the contrib modules you need
the PostgreSQL source. That is silly. If I have PostgreSQL installed
with all headers, I should be able to
download a PostgreSQL project app (pgAdmin whatever) and just build it
Neil Conway [EMAIL PROTECTED] writes:
Any thoughts on what could be causing these errors?
I suspect valgrind is complaining because XLogInsert is memcpy'ing a
struct that has allocation padding in it. Which of course is a bogus
complaint ...
regards, tom lane
Marc G. Fournier wrote:
On Wed, 21 Apr 2004, Joe Conway wrote:
- It is dependent on backend code to the extent that it cannot be built
outside of the contrib folder, unless some backend code is duplicated
in the external project. It also has no build system of its own.
k, so this one falls
On Thu, Apr 22, 2004 at 12:41:28AM +0400, Oleg Bartunov wrote:
The problem with moving all contribs to gborg is that sometimes it's
required to change many modules, for example, because of changing
GiST interface. Tom saves a lot of working for contrib authors, when he
change code in core. I'm
The point of projects.postgresql.org is that if someone *is* looking for
an addon, they should be pointed to projects.postgresql.org ... if you try
and merge everything into the -core distribution, you are either going to
miss something that *someone* wants to use at some point, *or* one
Hi all,
Who can give an authorative answer regarding distributing PostgreSQL
under a different license?
In particular, the front page claims that PostgreSQL is under the BSD
license. The problem is that there are two. The four clause license,
which is not GPL compatible, and the three clause,
Here's a draft of the solution that I'm currently working on for custom GUC
variables:
A new string variable 'custom_variable_classes' is introduced. This variable
is a comma separated string of identifiers. Each identifier denots a 'class'
that will allow its members to be added without error.
Alvaro Herrera wrote:
On Thu, Apr 22, 2004 at 12:29:36AM -0400, Bruce Momjian wrote:
I am thinking they could untar into a directory under pgsgl/ or have a
way to point to a 'configure'-run source tree and pull values from
there.
If you include pg_config.h, or use Makefile.global, you have
Shachar Shemesh [EMAIL PROTECTED] writes:
In particular, the front page claims that PostgreSQL is under the BSD
license. The problem is that there are two.
We use the one shown in the COPYRIGHT file in the top directory of the
source tree, which is also available for your reading pleasure by
On Tue, 20 Apr 2004, Bruce Momjian wrote:
I haven't yet seen the patch, but conceptually I'm conrned about how it
can handle situations like
this sequence
INSERT row X into database A
INSERT row X into database B
DBMIrror from A to B locks table
the mirror will fail.
Where are we on
Tom Lane wrote:
Shachar Shemesh [EMAIL PROTECTED] writes:
In particular, the front page claims that PostgreSQL is under the BSD
license. The problem is that there are two.
We use the one shown in the COPYRIGHT file in the top directory of the
source tree, which is also available for your
Tom Lane wrote:
Neil Conway [EMAIL PROTECTED] writes:
Any thoughts on what could be causing these errors?
I suspect valgrind is complaining because XLogInsert is memcpy'ing a
struct that has allocation padding in it. Which of course is a bogus
complaint ...
As far as I remember
Shachar Shemesh wrote:
Tom Lane wrote:
I suspect valgrind is complaining because XLogInsert is memcpy'ing a
struct that has allocation padding in it. Which of course is a bogus
complaint ...
As far as I remember (couldn't find modern documentation on the
matter) Valgrind is resitant to this
Shachar Shemesh [EMAIL PROTECTED] writes:
Neil Conway wrote:
What license text do you think implies this?
provided that the above copyright notice and this paragraph and the
following two paragraphs appear in all copies.
I read that to mean that all copies must have the same license.
No,
Neil Conway wrote:
On Thu, 2004-04-22 at 09:19, Shachar Shemesh wrote:
The license given in the web link you mention seems to mandate all
related work to be under the same license, which is nowhere near what
BSD means.
What license text do you think implies this?
-Neil
provided
On Thu, 2004-04-22 at 09:19, Shachar Shemesh wrote:
The license given in the web link you mention seems to mandate all
related work to be under the same license, which is nowhere near what
BSD means.
What license text do you think implies this?
-Neil
---(end of
Shachar Shemesh wrote:
Tom Lane wrote:
Shachar Shemesh [EMAIL PROTECTED] writes:
In particular, the front page claims that PostgreSQL is under the BSD
license. The problem is that there are two.
We use the one shown in the COPYRIGHT file in the top directory of the
source
Jan,
Josh, is there anything that remotely sounds like this in the new system
you're setting up?
Not AFAIK. I'm really not a CVS person (as you may have gathered), but I'm
under the impression that GForge is a pretty dumb user of CVS.
As far as I'm concerned, what you've suggested is
Neil Conway [EMAIL PROTECTED] writes:
Valgrind'ing the postmaster yields a fair number of errors. A lot of
them are similar, such as the following:
==29929== Use of uninitialised value of size 4
==29929==at 0x80AFB80: XLogInsert (xlog.c:570)
Oh, I see the issue. Shachar is correct that
Shachar Shemesh wrote:
Neil Conway wrote:
On Thu, 2004-04-22 at 09:19, Shachar Shemesh wrote:
The license given in the web link you mention seems to mandate all
related work to be under the same license, which is nowhere near what
BSD means.
What license text do you think
Kris,
Thank you. I objected to having the jdbc code moved out of the base
product cvs tree for some of the reasons being discussed in this thread:
how are people going to find the jdbc driver, how will they get
documentation for it, etc.
I think the core problem is that some people view
Peter Eisentraut wrote:
Shachar Shemesh wrote:
Can anyone shed more light on this point for me? Am I misreading
something? If it is possible to put code into an LGPL project, what
is the requirement?
You have to display the PostgreSQL license text in the source code or
the binary,
Min Xu (Hsu) wrote:
I am confused by how valgrind define make use of data? Isn't
copy data a type of make use? I mean, if valgrind checks if the
data was used as inputs of memcpy(), it is fine. But if user uses
his own memory_copy(), which loads the data into register,
as if the data is going to
Shachar Shemesh wrote:
Can anyone shed more light on this point for me? Am I misreading
something? If it is possible to put code into an LGPL project, what
is the requirement?
You have to display the PostgreSQL license text in the source code or
the binary, depending on what you ship. A
Taking into account that quite a few people have repeatedly stated that
the components in contrib are considered more supported/recommended than
similar solutions found on gborg or any other external site, I suggest
we move the projects dbmirror and dblink to gborg. The rserv contrib
module
I am also interested in this so I want to make some comments.
On Thu, 22 Apr 2004 Shachar Shemesh wrote :
Found it:
http://developer.kde.org/~sewardj/docs-2.0.0/mc_main.html, section 3.3.2
It is important to understand that your program can copy around junk
(uninitialised) data to its
Tom Lane wrote:
No, that says that you can't remove the copyright notice from files that
have it. It doesn't say that nearby files have to have the same
license. (Compare to the GPL, which *does* say that.)
The bottom line here is that you cannot relicense code you didn't write;
this is
Shachar Shemesh [EMAIL PROTECTED] writes:
Tom Lane wrote:
The original pad bytes may be fairly far removed from the point of the
error ... an example is that I was able to make one XLogInsert complaint
go away by changing palloc to palloc0 at tupdesc.c line 413 (in
TupleDescInitEntry), which
I agree with the notion that contrib be removed
from the main distribution. There is, however, a
disconnect between supporting projects and the main system.
Take a look at the www.postgresql.org web site.
Most people visually filter out the side bars. I've
been looking over effectiveness of
Tom Lane wrote:
==29929== Syscall param write(buf) contains uninitialised or
unaddressable byte(s)
The original pad bytes may be fairly far removed from the point of the
error ... an example is that I was able to make one XLogInsert complaint
go away by changing palloc to palloc0 at
Josh Berkus wrote:
We can't have *everything* in contrib -- the top 5 GUIs alone would triple the
size of our downloads. So we need to move in the opposite direction --
putting more stuff in pgFoundry, and letting packagers know that they should
package and include all mature projects on
Taking into account that quite a few people have repeatedly stated that
the components in contrib are considered more supported/recommended than
similar solutions found on gborg or any other external site, I suggest
we move the projects dbmirror and dblink to gborg. The rserv contrib
module seems
On Wed, 21 Apr 2004, Rod Taylor wrote:
I guess that is where we differ in opinion. pgadmin is not addon or an
enhancement, it is a part of the core project every bit as much as the
gnome-panel is a part of gnome. Sure, gnome-libs does all the heavy
lifting, but without the panel most users
On Wed, 21 Apr 2004, Bruce Momjian wrote:
Marc G. Fournier wrote:
On Wed, 21 Apr 2004, Bruce Momjian wrote:
There are only a few PostgreSQL developers who can do it, so what are
the odds that a single guy who maintains a plugin is going to be able to
do it. And you can say it is
As you know, we had libpq and ecpg threading available in 7.4 via a
configure flag.
However, threading required users to report their platform's configure
flags (something better done by configure) and run a thread test program
(src/tools/thread/thread_test).
For 7.5, I want to use:
I still think you should change the text on the front page to read, at
the very least, PostgreSQL is distributed under a flexible X11 like
license. BSD is too misleading, and most people know the X11 license
by now.
http://www.freebsd.org/copyright/freebsd-license.html
Marc G. Fournier wrote:
On Wed, 21 Apr 2004, Bruce Momjian wrote:
Marc G. Fournier wrote:
On Wed, 21 Apr 2004, Bruce Momjian wrote:
There are only a few PostgreSQL developers who can do it, so what are
the odds that a single guy who maintains a plugin is going to be able to
On Thu, 2004-04-22 at 20:09, Marc G. Fournier wrote:
On Wed, 21 Apr 2004, Rod Taylor wrote:
I guess that is where we differ in opinion. pgadmin is not addon or an
enhancement, it is a part of the core project every bit as much as the
gnome-panel is a part of gnome. Sure, gnome-libs does
Bruce Momjian wrote:
Marc G. Fournier wrote:
Right, but you don't count ... you aren't an end-user
True, but what the end users get is nothing because I don't have the
time. No configure, no build environment, very user-unfriendly.
Exactly.
Joe
---(end of
Joe Conway [EMAIL PROTECTED] writes:
As I've said on other parts of this thread, my concern with moving
everything to gborg/pgFoundry is that it raises the bar in terms of
difficulty if we expect every individual project to develop their own
infrastructure.
I think that's exactly right.
Jeff Davis [EMAIL PROTECTED] writes:
Also, can you license code at all if it isn't yours? I would assume you
would have to make changes and license the changes you made, and
distribute it along with the postgresql-licensed code.
You can't relicense code you don't own (if Shachar thinks
On Thursday 22 April 2004 13:55, Barry Lind wrote:
I think the solution lies in improving www.postgresql.org. At the end
of the day it doesn't matter where source code lives, what matters is
can people find what they are expecting. Given we know what people are
looking for, that should be
On Wed, 21 Apr 2004, Joe Conway wrote:
On Wed, 21 Apr 2004, Joe Conway wrote:
No, I don't call that lazy, I call it smart. It makes use (reuse) of a
part of Postgres (the contrib build system) that is among its strengths.
Is it your goal to make it harder for people to write their own C
Tom Lane wrote:
Joe Conway [EMAIL PROTECTED] writes:
As I've said on other parts of this thread, my concern with moving
everything to gborg/pgFoundry is that it raises the bar in terms of
difficulty if we expect every individual project to develop their own
infrastructure.
I think
On Tuesday 20 April 2004 16:54, Andrew Dunstan wrote:
Joshua D. Drake wrote:
g a data store for many databases, not a single database. But I
think it is far too sanctified by history to change now, just as Ken
Thompson now wishes he had put an 'e' on the end of 'creat' but can't
go back
Marc G. Fournier wrote:
On Wed, 21 Apr 2004, Joe Conway wrote:
On Wed, 21 Apr 2004, Joe Conway wrote:
No, I don't call that lazy, I call it smart. It makes use (reuse) of a
part of Postgres (the contrib build system) that is among its strengths.
Is it your goal to make it harder for
On Thu, 22 Apr 2004, Bruce Momjian wrote:
OK, I think the number of files needed to build modules is small and I
think can be installed by default in a /build directory. I am thinking
that with a little script help, projects can build apps that look like
like Makefiles used in our core
Here is a blog about a recent MySQL conference with title, Why MySQL
Grew So Fast:
http://www.oreillynet.com/pub/wlg/4715
and a a Slashdot discussion about it:
http://developers.slashdot.org/article.pl?sid=04/04/20/2229212mode=nestedtid=137tid=185tid=187tid=198
My question is,
Bruce Momjian [EMAIL PROTECTED] writes:
What if we create a build/ directory as part of install that
pg_config.h, Makefile.global, etc, anything a plugin would need, and
install it by default. Then, if we give folks an easy way to access
them from their own apps and Makefiles, it would solve
Tom Lane wrote:
Jeff Davis [EMAIL PROTECTED] writes:
Also, can you license code at all if it isn't yours? I would assume you
would have to make changes and license the changes you made, and
distribute it along with the postgresql-licensed code.
You can't relicense code you don't own
Sure
On Thu, 22 Apr 2004, Shachar Shemesh wrote:
Tom Lane wrote:
You can take some Postgres pieces and use them in a project with a
different overall license, but those pieces are still under BSD license.
But that's not the BSD license.
[...]
The BSD license, in contrast to PostgreSQL's,
54 matches
Mail list logo
