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
===
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
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
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
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
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
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
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
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
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
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 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)
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
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
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 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
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
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
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:
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
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:
> 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
22 matches
Mail list logo