-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andrus
Sent: 08 May 2006 18:16
To: pgadmin-hackers@postgresql.org
Subject: Re: [pgadmin-hackers] Adminpack contrib module
There were no objections, so attached is an updated version of the
Am Samstag, 29. April 2006 21:27 schrieb Martijn van Oosterhout:
What it does is remove the restriction that any one program can only
use (directly or indirectly) one version of libpq at any moment.
Programs can use indirectly postgres via PAM or NSS or other such
pluggable interfaces.
Am Freitag, 5. Mai 2006 20:07 schrieb Martijn van Oosterhout:
1. Provide an escape option they can add
2. Package systems can usually apply patches prior to compiling, they can
always remove the offending line if they like.
3. Try and get feedback from them now rather than wait
My feedback is
On Tue, May 09, 2006 at 10:19:56AM +0200, Peter Eisentraut wrote:
Am Samstag, 29. April 2006 21:27 schrieb Martijn van Oosterhout:
What it does is remove the restriction that any one program can only
use (directly or indirectly) one version of libpq at any moment.
Programs can use
On 5/9/06, Peter Eisentraut [EMAIL PROTECTED] wrote:
Am Freitag, 5. Mai 2006 20:07 schrieb Martijn van Oosterhout:
1. Provide an escape option they can add
2. Package systems can usually apply patches prior to compiling, they can
always remove the offending line if they like.
3. Try and get
On Tue, May 09, 2006 at 10:37:43AM +0200, Peter Eisentraut wrote:
Am Freitag, 5. Mai 2006 20:07 schrieb Martijn van Oosterhout:
1. Provide an escape option they can add
2. Package systems can usually apply patches prior to compiling, they can
always remove the offending line if they like.
Yep, the pipe.c patch is unnecessary now.
Pete
Bruce Momjian pgman@candle.pha.pa.us 05/07/06 3:44 am
Now that we know the cause of the Win32 failure (FRONTEND), we don't
need the Win32 part of this patch anymore right?
---(end of broadcast)---
Bruce Momjian wrote:
I am thinking we just add another column to the \d display for sequences
showing the current value.
---
As suggested in the previous mails, I tried to use the following to
display the seq. value.
Am Dienstag, 9. Mai 2006 10:41 schrieb Martijn van Oosterhout:
Depends what you mean by signature. The structures of PGconn and
PGresult have changed over time, so if you you pass a PGresult
allocated by libpq4 to a function in libpq3, it'll crash.
Symbol versioning only affects functions (and
Am Dienstag, 9. Mai 2006 10:55 schrieb Martijn van Oosterhout:
Can you explain why? Unknown options don't do anything, so having users
remove them seems like a good move.
Build system frameworks assume that they can pass any option and that unknown
options will be ignored. This grew out of
On Tue, May 09, 2006 at 01:50:38PM +0200, Peter Eisentraut wrote:
Am Dienstag, 9. Mai 2006 10:41 schrieb Martijn van Oosterhout:
Depends what you mean by signature. The structures of PGconn and
PGresult have changed over time, so if you you pass a PGresult
allocated by libpq4 to a function
Martijn van Oosterhout kleptog@svana.org writes:
Eh? It stops a program expecting libpq4 being linked to libpq3 for any
reason, so the above situation can't happen. You don't need to version
any structs, only the functions using them.
If we have an existing app built against an unversioned
Dhanaraj M [EMAIL PROTECTED] writes:
However, it was not possible to display the seq. value using this.
Hence, I made a small change in the currval() function, so that it
retrieves the last_value
even if the the value is not cached.
Breaking currval()'s semantics is not an acceptable
Dear Bruce san.
I may be quite persistent.:-)
I seasoned the proposal method. It was very painful that the
conventional connection method to this password was a plain text.
Although I am simple, I desire the support. Furthermore, the relation
between a field item and an environment variable is
On Tue, May 09, 2006 at 09:18:17AM -0400, Tom Lane wrote:
Martijn van Oosterhout kleptog@svana.org writes:
Eh? It stops a program expecting libpq4 being linked to libpq3 for any
reason, so the above situation can't happen. You don't need to version
any structs, only the functions using
Marko Kreen wrote:
On 5/9/06, Peter Eisentraut [EMAIL PROTECTED] wrote:
Am Freitag, 5. Mai 2006 20:07 schrieb Martijn van Oosterhout:
1. Provide an escape option they can add
2. Package systems can usually apply patches prior to compiling, they can
always remove the offending line if
Hiroshi Saito [EMAIL PROTECTED] writes:
I may be quite persistent.:-)
I seasoned the proposal method. It was very painful that the
conventional connection method to this password was a plain text.
Although I am simple, I desire the support. Furthermore, the relation
between a field item and
From: Tom Lane [EMAIL PROTECTED]
What is the point of this? It seems to be complicating life to little
purpose (except storing passwords that will fail in non-MD5 password
methods --- given that people are talking about replacing MD5, that
doesn't seem like a good forward-looking idea).
On Tue, May 09, 2006 at 11:35:32AM -0400, Bruce Momjian wrote:
So at the end of configure the user can visually confirm
his expectations without needing to parse the noise
from full configure output. Maybe this would be better
solution.
Seems we would be best printing out options we
Dear Tom,
I think that the inability to convert nearly binary compatible standard
types one to the other is a postgresql issue. Even if it is not often
useful, the point is completeness and soundness of the type provided by
the core.
OK, can I get some feedback from others about this patch?
On Tue, 2006-05-09 at 22:37 +0200, Martijn van Oosterhout wrote:
This was a suggestion made back in March that would dramatically reduce
the overhead of EXPLAIN ANALYZE on queries that loop continuously over
the same nodes.
http://archives.postgresql.org/pgsql-hackers/2006-03/msg01114.php
- To get this close it needs to get an estimate of the sampling
overhead.
It does this by a little calibration loop that is run once per
backend.
If you don't do this, you end up assuming all tuples take the same
time
as tuples with the overhead, resulting in nodes apparently taking
longer
On Tue, May 09, 2006 at 05:16:57PM -0400, Rocco Altier wrote:
- To get this close it needs to get an estimate of the sampling
overhead. It does this by a little calibration loop that is run
once per backend. If you don't do this, you end up assuming all
tuples take the same time as tuples
23 matches
Mail list logo
