Please ignore- seems some old mail of mine got sent waaay late...
Christopher Kings-Lynne wrote:
While fixing the gui for pg_dump and pg_restore, I painfully noticed
there's no option for the password.
After some tests, I found that using the PGPASSWORD environment
variable will do the job. I'm a
Tom,
Your patch works for my test cases. Thanks to both you and Oliver for
getting this fixed.
--Barry
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 28, 2004 2:23 PM
To: Oliver Jowett
Cc: Barry Lind; [EMAIL PROTECTED]
Subject: Re: [HACKERS] [JDBC]
While fixing the gui for pg_dump and pg_restore, I painfully noticed
there's no option for the password.
After some tests, I found that using the PGPASSWORD environment variable
will do the job. I'm a bit irritated that it's marked "deprecated" in
the docs, the .pgpass solution isn't a good one
In case anyone is interested, I've posted 8.0.0beta5 rpms here:
http://www.joeconway.com/postgresql-8.0.0beta/
Note that these are not "official" PGDG rpms, just my own home brew.
Also note that there is talk of an imminent RC1 -- hopefully I'll find
time to update the rpms within a day or so
Tom Lane wrote:
> Mike Mascari <[EMAIL PROTECTED]> writes:
> > Will ANALYZE continue to ignore columns whose data is composed entirely
> > of NULL in 8.0?
>
> I had hoped to get to this before RC, but it looks like it won't happen.
> Considering I've just been beating up on Bruce for committing s
Mike Mascari <[EMAIL PROTECTED]> writes:
> Will ANALYZE continue to ignore columns whose data is composed entirely
> of NULL in 8.0?
I had hoped to get to this before RC, but it looks like it won't happen.
Considering I've just been beating up on Bruce for committing stuff that
wasn't clearly a b
On Fri, 3 Dec 2004 01:43 pm, Michael Fuhr wrote:
> gcc 3.4.2 on Solaris 9 doesn't complain about this.
Yes, I found Tom's response to the issue from March here:
http://archives.postgresql.org/pgsql-ports/2004-03/msg9.php
and this on the Sun CC forum, confirming that the compiler is borked:
ht
On Fri, Dec 03, 2004 at 11:31:19AM +1100, Philip Yarra wrote:
> Hi all, before I delve too deeply into this, has anyone else tried building
> 7.4.6 on Solaris 9 (sparc) ? I'm seeing build failures using Sun's cc:
>
> make[4]: Entering directory `/tmp/postgresql-7.4.6/src/backend/access/heap'
> c
I've tried emailling David Fetter to no avail; anyone know who's in
charge of the torrents or anyone who can answer my original question?
- Forwarded message from "Jim C. Nasby" <[EMAIL PROTECTED]> -
Date: Tue, 23 Nov 2004 15:52:15 -0600
From: "Jim C. Nasby" <[EMAIL PROTECTED]>
To: [EMAIL
Neil Conway wrote:
> On Thu, 2004-12-02 at 09:59 -0500, Bruce Momjian wrote:
> > OK, either you have to own the issue or I have to add something to the
> > TODO list.
>
> Can you add it to the TODO list and assign it to me?
>
Done:
* Fix priority ordering of read and write light-weight
On Thu, 2004-12-02 at 09:59 -0500, Bruce Momjian wrote:
> OK, either you have to own the issue or I have to add something to the
> TODO list.
Can you add it to the TODO list and assign it to me?
-Neil
---(end of broadcast)---
TIP 3: if posting/re
On Thu, 2004-12-02 at 20:51 -0500, Tom Lane wrote:
> No. The current code involves two pallocs per cycle, one inside the
> aggregate function to construct its result value, and then one in
> datumCopy to copy the result into the proper context.
Ah, true -- missed the fact that PG_RETURN_INT64() d
Great. Documentation of the source code helps many developers become
more productive.
---
Gevik Babakhani wrote:
> I think the basis in understanding how PostgreSQL works depends
> on the documentation to certain extend an
I think the basis in understanding how PostgreSQL works depends
on the documentation to certain extend and the level of one's programming
and database knowledge of course.
At this moment I am gathering information from anywhere I can get a hold
of regarding PostgresSQL.
I have requested a repo
Neil Conway <[EMAIL PROTECTED]> writes:
> - yours would mean that int8inc() and similar aggregates wouldn't ever
> need to do palloc(); mine would require a palloc() every k calls to the
> transition function.
No. The current code involves two pallocs per cycle, one inside the
aggregate function
On Thu, 2004-12-02 at 19:07 -0500, Tom Lane wrote:
> True, but you still have to palloc if it returns the second argument.
Is that common? In any case, I don't see how you can _ever_ avoid a
palloc if the aggregate returns the second argument. The second argument
is in a per-tuple memory context:
I have backed out this patch. It is unclear it is a bug fix.
It will be saved for 8.1.
---
pgman wrote:
>
> Patch applied. Thanks.
>
> ---
>
>
>
On Thu, 2004-12-02 at 10:58 +0100, Gevik Babakhani wrote:
> I was wondering if there are any interests or plans for documenting
> various functions in the code which currently are not documented.
I don't know of any systematic effort to do this. I try to document
undocumented code as necessary wh
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > One more issue. Until we start RC, patches that are bug fixes will
> > continue to be applied. Do we want that? By going RC we are basically
> > saying we need to focus on docs and packaging and we perhaps can keep
> > fixes for 8.0
Philip Yarra <[EMAIL PROTECTED]> writes:
> Hi all, before I delve too deeply into this, has anyone else tried building
> 7.4.6 on Solaris 9 (sparc) ? I'm seeing build failures using Sun's cc:
> make[4]: Entering directory `/tmp/postgresql-7.4.6/src/backend/access/heap'
> cc -Xa -O -v -I../../../.
Bruce Momjian <[EMAIL PROTECTED]> writes:
> One more issue. Until we start RC, patches that are bug fixes will
> continue to be applied. Do we want that? By going RC we are basically
> saying we need to focus on docs and packaging and we perhaps can keep
> fixes for 8.0.1.
In my mind "RC" means
Marc G. Fournier wrote:
> On Thu, 2 Dec 2004, Bruce Momjian wrote:
>
> > One more issue. Until we start RC, patches that are bug fixes will
> > continue to be applied. Do we want that? By going RC we are basically
> > saying we need to focus on docs and packaging and we perhaps can keep
> >
On Thu, 2 Dec 2004, Bruce Momjian wrote:
One more issue. Until we start RC, patches that are bug fixes will
continue to be applied. Do we want that? By going RC we are basically
saying we need to focus on docs and packaging and we perhaps can keep
fixes for 8.0.1.
critical bug fixes should be
Bruce Momjian wrote:
> Marc G. Fournier wrote:
> > On Fri, 3 Dec 2004, Peter Eisentraut wrote:
> >
> > > Bruce Momjian wrote:
> > >> I have applied all outstanding patches and I think we are ready to go
> > >> for RC1.
> > >
> > > Considering that you just added at least three new and completely
>
Peter Eisentraut wrote:
Andrew Dunstan wrote:
If you have something missing from here I'm especially interested in
hearing from you.
I think "Linux" entries are quite useless. We need to know what
distribution (and version) it is. The kernel is actually a pretty
uninteresting part of t
Marc G. Fournier wrote:
> On Fri, 3 Dec 2004, Peter Eisentraut wrote:
>
> > Bruce Momjian wrote:
> >> I have applied all outstanding patches and I think we are ready to go
> >> for RC1.
> >
> > Considering that you just added at least three new and completely
> > untested features, I don't think R
On Thu, 2 Dec 2004, Bruce Momjian wrote:
Here is an updated open items list. The first three items are the ones
that are going to be closed tomorrow and moved to the TODO list. I
already moved the terminal server issue to the TODO list.
'k, will watch for commits on these before doing the RC1 ...
On Fri, 3 Dec 2004, Peter Eisentraut wrote:
Bruce Momjian wrote:
I have applied all outstanding patches and I think we are ready to go
for RC1.
Considering that you just added at least three new and completely
untested features, I don't think RC1 is the way to go.
I have to agree here ... I'd do a
Hi all, before I delve too deeply into this, has anyone else tried building
7.4.6 on Solaris 9 (sparc) ? I'm seeing build failures using Sun's cc:
make[4]: Entering directory `/tmp/postgresql-7.4.6/src/backend/access/heap'
cc -Xa -O -v -I../../../../src/include -c -o tuptoaster.o tuptoaster.c
"
Andrew Dunstan wrote:
> If you have something missing from here I'm especially interested in
> hearing from you.
I think "Linux" entries are quite useless. We need to know what
distribution (and version) it is. The kernel is actually a pretty
uninteresting part of the porting process.
--
Pet
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
+ if (!embedded_line_warning && (c == '\n' || c == '\r') )
+ {
+ embedded_line_warning = true;
+ elog(WARNING,
+ "CSV fields with embedded linefeed or carriage return "
+ "characters might not be able to be reimport
Tom Lane wrote:
> We never really issued a "call for port reports" as has been past
> practice. I think that Andrew Dunstan's build farm has partially
> obsoleted that custom, but if you have access to a platform that
> is not represented in the build farm, please do give it a try soon.
The platf
Bruce Momjian wrote:
> I have applied all outstanding patches and I think we are ready to go
> for RC1.
Considering that you just added at least three new and completely
untested features, I don't think RC1 is the way to go.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
Travis P wrote:
On Dec 2, 2004, at 5:44 PM, Andrew Dunstan wrote:
http://pgfoundry.org/projects/pgbuildfarm/
I started work today on a page that lists all the members.
Ah, good. I'm not seeing it immediately, but I'll keep my eye out.
I've an AIX 5.1 system on which I could try to compile if y
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> + if (!embedded_line_warning && (c == '\n' || c == '\r') )
> + {
> + embedded_line_warning = true;
> + elog(WARNING,
> + "CSV fields with embedded linefeed or c
Neil Conway <[EMAIL PROTECTED]> writes:
> On Thu, 2004-12-02 at 10:45 -0500, Tom Lane wrote:
>> (2) I think you lose much of the performance
>> benefit as soon as you have to distinguish cases (b) and (c).
> Why wouldn't a simple comparison work? We're passing two arguments into
> the aggregate fu
I wrote:
If it bothers you that much. I'd make a flag, cleared at the start of
each COPY, and then where we test for CR or LF in CopyAttributeOutCSV,
if the flag is not set then set it and issue the warning.
I didn't realise until Bruce told me just now that I was on the hook for
this. I guess
On Thu, 2004-12-02 at 10:45 -0500, Tom Lane wrote:
> (2) I think you lose much of the performance
> benefit as soon as you have to distinguish cases (b) and (c). Ideally
> you would use MemoryContextContains for this, but that doesn't work
> reliably on pointers that point to fields of a tuple.
W
On Dec 2, 2004, at 5:44 PM, Andrew Dunstan wrote:
http://pgfoundry.org/projects/pgbuildfarm/
I started work today on a page that lists all the members.
Ah, good. I'm not seeing it immediately, but I'll keep my eye out.
I've an AIX 5.1 system on which I could try to compile if you don't
have one
Bruce Momjian <[EMAIL PROTECTED]> wrote:
>
>
> You will be glad to know that 8.0 will use a different implementation
> for thread handling of SIGPIPE, though your asynchronous handling of
> SIGPIPE will still cause problems.
So-noted.
Jim
---(end of broadcast)--
> I am going to discard these emails. We haven't solve the Win32 terminal
> server problem and I think it needs to be moved to the TODO list instead.
Yes, please do that. I do not think there is a problem on TS other than some
missing permissions. The patch was only intended to avoid starting 2
Tom Lane <[EMAIL PROTECTED]> wrote:
>
> [EMAIL PROTECTED] (Jim Seymour) writes:
> > I'm kind of wondering if anybody on the dev team noticed this and
> > what, if anything, they planned to do with it?
>
> Can we make it "#ifdef SOLARIS7" somehow? I'm uneager to put a
> performance penalty on eve
Tom Lane wrote:
Travis P <[EMAIL PROTECTED]> writes:
What platforms are covered by the build farm?
See
http://www.pgbuildfarm.org/cgi-bin/show_status.pl
Also I think there is a gborg project page for it.
s/gborg/pgfoundry/
http://pgfoundry.org/projects/pgbuildfarm/
I started work today
Travis P <[EMAIL PROTECTED]> writes:
> What platforms are covered by the build farm?
See
http://www.pgbuildfarm.org/cgi-bin/show_status.pl
Also I think there is a gborg project page for it.
regards, tom lane
---(end of broadcast)--
On Dec 2, 2004, at 11:08 AM, Tom Lane wrote:
We never really issued a "call for port reports" as has been past
practice. I think that Andrew Dunstan's build farm has partially
obsoleted that custom, but if you have access to a platform that
is not represented in the build farm, please do give it a
Here is an updated open items list. The first three items are the ones
that are going to be closed tomorrow and moved to the TODO list. I
already moved the terminal server issue to the TODO list.
---
I am going to discard these emails. We haven't solve the Win32 terminal
server problem and I think it needs to be moved to the TODO list instead.
---
Zeugswetter Andreas DAZ SD wrote:
>
> > o fix shared memory on Win2k
I have applied all outstanding patches and I think we are ready to go
for RC1. These are the open items. I think we will just have to move
them to the TODO list tomorrow, except for the documentation items.
---
Patch applied. Thanks.
---
Dave Page wrote:
>
>
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf
> > Of Bruce Momjian
> > Sent: 27 November 2004 04:33
> > To: [EMAIL P
Patch applied. Thanks.
---
John Hansen wrote:
> 3 times lucky?
>
> Last one broke utf8 G
>
> This one works, Too tired, sorry for the inconvenience..
>
> ... John
Content-Description: cvs.diff
[ Attachment
Kris Jurka <[EMAIL PROTECTED]> writes:
> On Thu, 2 Dec 2004, Tom Lane wrote:
>> Reading between the lines, I wonder if your problem is that your copy of
>> editline puts its headers in include/readline rather than
>> include/editline?
> Yes, this is the actual problem readline.h is indeed in
> /u
On Thu, 2 Dec 2004, Tom Lane wrote:
> Reading between the lines, I wonder if your problem is that your copy of
> editline puts its headers in include/readline rather than
> include/editline?
>
Yes, this is the actual problem readline.h is indeed in
/usr/include/readline.. The missing symbols
Tom Lane wrote:
The core committee has agreed that it's about time to advance to Release
Candidate status (which we define as "code is frozen, but not docs nor
message translation work"). Barring surprises, 8.0RC1 will be wrapped
tomorrow (Friday).
We never really issued a "call for port reports"
Jan,
... plus that the catch-nesting automatically represents the
subtransaction nesting. I can't really see any reason why those two
should not be bound together. Does anybody?
That depends on what you mean. As a stop-gap solution, cerntanly. But in
the long run, I still think that savepoints a
Kris Jurka <[EMAIL PROTECTED]> writes:
> This recent change to readline/libedit selection isn't quite right.
> http://archives.postgresql.org/pgsql-committers/2004-11/msg00330.php
I found the reason for not linking to libtermcap --- there was an
ancient netbsd-specific hack that wasn't general-pur
On Thu, 2004-12-02 at 02:21 -0500, Greg Stark wrote:
> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
>
> > John wanted us to allow use of the 'locale' and 'utf8' pragmas in trusted
> > code.
>
> You know, there's something twisted in postgres's naming scheme here. How is
> it that "trusted" langu
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> John wanted us to allow use of the 'locale' and 'utf8' pragmas in trusted
> code.
You know, there's something twisted in postgres's naming scheme here. How is
it that "trusted" languages the ones that need a sandbox? and "untrusted"
languages the o
Neil Conway wrote:
> On Sat, 2004-11-27 at 23:11 -0500, Bruce Momjian wrote:
> > Is there a TODO here? Or a few?
>
> Sure: you could add a TODO item like "Improve psql schema behavior", and
> assign it to me. I'll send in a patch that implements the behavior I
> proposed for 8.1
Added to TODO:
Neil Conway <[EMAIL PROTECTED]> wrote on 02.12.2004, 05:55:43:
> On Wed, 2004-12-01 at 21:51 -0500, Bruce Momjian wrote:
> > Neil, where are we on this? Should we add comments? Add a TODO? A patch?
>
> I'm not sure what the right resolution is. As I said, I don't think it's
> wise to apply a p
The core committee has agreed that it's about time to advance to Release
Candidate status (which we define as "code is frozen, but not docs nor
message translation work"). Barring surprises, 8.0RC1 will be wrapped
tomorrow (Friday).
We never really issued a "call for port reports" as has been pas
Hi there,
there are several new contributed docs on tsearch2 page:
# How to use tsearch2 in Japanese
# Tsearch2 and Unicode/UTF-8
# Howto write my own parser for tsearch2
Thanks to Junji TERAMOTO, Markus Wollny and Valli for their work !
Regards,
Oleg
_
On Wed, Dec 01, 2004 at 10:04:43PM -0500, Tom Lane wrote:
> "Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> > I've raised this before, but would like to suggest again that there might be
> > virtue in branching earlier in the dev cycle - maybe around the time of the
> > first beta.
>
> Given the am
Neil Conway <[EMAIL PROTECTED]> wrote on 02.12.2004, 05:05:12:
> On Wed, 2004-12-01 at 19:34 +0100, [EMAIL PROTECTED] wrote:
> > I regard performance testing as an essential part of the
> > release process of any performance critical software. Most earlier beta
> > releases were fixing functional
Dear People,
I was wondering if there are any interests or plans for documenting
various functions in the code which currently are not documented.
I would like to start this discussion to see if we want to do this.
If I am the first one with this suggestion (I can't imagine) then I am
very in
Tom Lane wrote:
Not really: it only solves the problem *if you change the application*,
which is IMHO not acceptable. In particular, why should a non-threaded
app expect to have to change to deal with this issue? But we can't
safely build a thread-safe libpq.so for general use if it breaks
non-th
Dear People,
I was wondering if there are any interests or plans for documenting
various functions in the code which currently are not documented.
I would like to start this discussion to see if we want to do this.
If I am the first one with this suggestion (I can't imagine) then I am
very intere
Tom Lane wrote:
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
I've raised this before, but would like to suggest again that there might be
virtue in branching earlier in the dev cycle - maybe around the time of the
first beta.
Given the amount of patching that's gone on, branching 8.1 earli
Tom Lane wrote:
> Manfred Spraul <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Not really: it only solves the problem *if you change the application*,
> >> which is IMHO not acceptable.
>
> > No. non-threaded apps do not need to change. The default is the old, 7.3
> > code: change the sign
Manfred Spraul <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Not really: it only solves the problem *if you change the application*,
>> which is IMHO not acceptable.
> No. non-threaded apps do not need to change. The default is the old, 7.3
> code: change the signal handler around the write ca
Neil Conway <[EMAIL PROTECTED]> writes:
> ISTM it would be reasonable to mandate that aggregate authors return one
> of three things from their state transition functions:
> (a) return the previous state value
> (b) return the "next data item" value
> (c) return some other value; if by a pas
Kris Jurka <[EMAIL PROTECTED]> writes:
> This recent change to readline/libedit selection isn't quite right.
If you see a problem you'll have to give more details ...
> It doesn't link in libtermcap with libedit which leads to:
Certainly it tries that.
> checking for readline.h... no
> configur
OK, either you have to own the issue or I have to add something to the
TODO list.
---
Neil Conway wrote:
> On Wed, 2004-12-01 at 21:51 -0500, Bruce Momjian wrote:
> > Neil, where are we on this? Should we add comments? Add
Manfred Spraul wrote:
> Tom Lane wrote:
>
> >Not really: it only solves the problem *if you change the application*,
> >which is IMHO not acceptable. In particular, why should a non-threaded
> >app expect to have to change to deal with this issue? But we can't
> >safely build a thread-safe libpq
73 matches
Mail list logo
