Neil Conway wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I think there was an updated BSD license approved by Berkeley that
> > we are using.
>
> I think this is an area where we need a higher degree of certainty
> than that.
I think our BSD license version came from FreeBSD.
--
Bru
Manfred Spraul wrote:
> Bruce Momjian wrote:
>
> >OK, I know you had a flag for pgbench, and that doesn't use threads.
> >What speedup do you see there?
> >
> >
> Tiny. I added the flag to check that my implementation works, not as a
> benchmark tool.
>
> >I would not expect a library to requ
Neil Conway wrote:
To summarize, my understanding is that there are two problems:
(1) Some of the files in the main source tree are 4 clause
BSD. Since PostgreSQL is "derived" from these files, we fall
under its licensing restrictions, namely the advertising
clause.
I don
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think there was an updated BSD license approved by Berkeley that
> we are using.
I think this is an area where we need a higher degree of certainty
than that.
> If we took the file unchanged, I would not remove the copyright
> because it is the file _
Neil Conway wrote:
A quick grep of the source tree indicates that the following files
claim to be covered by the 4 clause BSD license:
$ grep -rlI 'This product includes software developed' *
contrib/mysql/my2pg.pl
contrib/pgcrypto/README.pgcrypto
contrib/pgcrypto/blf.c
You must be careful wit
I think there was an updated BSD license approved by Berkeley that we
are using.
If we took the file unchanged, I would not remove the copyright because
it is the file _unchanged_, no?
---
Neil Conway wrote:
> Bruce Momjian
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I don't change the copyright, but I think we can take the copyright
> of the project rather than those of the individual files.
So can we remove the offending license clauses, then?
Also, it's worth noting that the license in 'COPYRIGHT' is not exactly
Yes, in cases where I take the entire file unchanged, I don't change the
copyright, but I think we can take the copyright of the project rather
than those of the individual files.
---
Neil Conway wrote:
> Bruce Momjian <[EMA
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have grabbed code from NetBSD before, and I just mention that fact at
> the top of the file. There is no need to repeat their license as it is
> the same as our license.
src/port/qsort.c is wrong, then: (a) it includes the full NetBSD
copyright/warran
Bruce Momjian wrote:
I have grabbed code from NetBSD before, and I just mention that fact at
the top of the file. There is no need to repeat their license as it is
the same as our license.
I just added the last line:
* Portions Copyright (c) 1996-2003, PostgreSQL Global Development Group
* Porti
I have grabbed code from NetBSD before, and I just mention that fact at
the top of the file. There is no need to repeat their license as it is
the same as our license.
I just added the last line:
* Portions Copyright (c) 1996-2003, PostgreSQL Global Development Group
* Portions Copyright (c)
This patch refactors CreateTupleDescCopy() and
CreateTupleDescCopyConstr() to remove some duplicated code, and clean
things up a little bit.
-Neil
Index: src/backend/access/common/tupdesc.c
===
RCS file: /var/lib/cvs/pgsql-server/src/
I wrote:
Rod Taylor wrote:
On Mon, 2003-11-17 at 14:11, Andrew Dunstan wrote:
Neil Conway asked me if we need a copyright notice to cover the code I
borrowed from FreeBSD in initdb.c. I wasn't sure, but in case we do
here
is a patch to include it.
Unless I'm mistaken, all of the FreeBSD
Rod Taylor wrote:
On Mon, 2003-11-17 at 14:11, Andrew Dunstan wrote:
Neil Conway asked me if we need a copyright notice to cover the code I
borrowed from FreeBSD in initdb.c. I wasn't sure, but in case we do here
is a patch to include it.
Unless I'm mistaken, all of the FreeBSD code is und
On Mon, 2003-11-17 at 14:11, Andrew Dunstan wrote:
> Neil Conway asked me if we need a copyright notice to cover the code I
> borrowed from FreeBSD in initdb.c. I wasn't sure, but in case we do here
> is a patch to include it.
Unless I'm mistaken, all of the FreeBSD code is under the 3 clause
lice
Neil Conway asked me if we need a copyright notice to cover the code I
borrowed from FreeBSD in initdb.c. I wasn't sure, but in case we do here
is a patch to include it.
cheers
andrew
Index: initdb.c
===
RCS file: /projects/cvsroot/p
Neil Conway <[EMAIL PROTECTED]> writes:
> There are currently two problems/caveats with the patch [...]
I just wanted to check that no one had any input or comments on the
issues described in the original email -- "Speak now, or forever..."
:-)
I'm thinking of solving both problems by doing LISTE
Bruce Momjian wrote:
OK, I know you had a flag for pgbench, and that doesn't use threads.
What speedup do you see there?
Tiny. I added the flag to check that my implementation works, not as a
benchmark tool.
I would not expect a library to require me to do something in my code to
be thread-s
Manfred Spraul wrote:
> Bruce Momjian wrote:
>
> >Here is my logic --- 99% of apps don't install a SIGPIPE signal handler,
> >and 90% will not add a SIGPIPE/SIG_IGN call to their applications. I
> >guess I am looking for something that would allow the performance
> >benefit of not doing a pgsigna
Hannu Krosing wrote:
> Bruce Momjian kirjutas E, 17.11.2003 kell 03:58:
>
> >
> > OK, let me give you my logic and you can tell me where I am wrong.
> >
> > First, how many backend can a single write process support if all the
> > backends are doing insert/update/deletes? 5? 10? Let's assume
Bruce Momjian kirjutas E, 17.11.2003 kell 03:58:
>
> OK, let me give you my logic and you can tell me where I am wrong.
>
> First, how many backend can a single write process support if all the
> backends are doing insert/update/deletes? 5? 10? Let's assume 10.
> Second, once we change write
This makes help like this:
\lo_export LOBOID FILE
\lo_import FILE [COMMENT]
\lo_list
\lo_unlink LOBOIDlarge object operations
Instead of not saying anything about what arguments are required.
Chris
Index: src/bin/psql/help.c
===
22 matches
Mail list logo
