Bruce Momjian wrote:
The idea of the patch number in the subject line works with that
streaming model because it merely marks streams so they can be grouped.
The defining event that marks the stream is a post to the patches list.
We already number posts to the bugs list, so in a way we could
On May 5, 2007, at 11:40 AM, Dave Page wrote:
snip tracker outline
Barring a few trivial details, that sounds almost identical to
what I
proposed.
Well, Andrew says everyone he talks to doesn't want it. They want a
more comprehensive solution that goes from bug to patch.
I don't recall
On May 6, 2007, at 9:32 AM, Tom Lane wrote:
Jim Nasby [EMAIL PROTECTED] writes:
There's several problems with that. First, trace_sort isn't
documented (or at least it's not in postgresql.conf), so most folks
don't know it exists. Second, in order to see it's output you have to
drop
Dave Page wrote:
Bruce Momjian wrote:
The idea of the patch number in the subject line works with that
streaming model because it merely marks streams so they can be grouped.
The defining event that marks the stream is a post to the patches list.
We already number posts to the bugs list, so
On May 5, 2007, at 10:38 AM, Neil Conway wrote:
On Sat, 2007-05-05 at 11:03 -0400, Tom Lane wrote:
I'm not necessarily opposed to changing the default configure
selection,
but I am opposed to removing the FP code entirely.
I would be satisfied with changing the default to integer and
Jim Nasby [EMAIL PROTECTED] writes:
There's several problems with that. First, trace_sort isn't
documented (or at least it's not in postgresql.conf), so most folks
don't know it exists. Second, in order to see it's output you have to
drop log_min_messages to debug. That results in a huge
Peter Eisentraut wrote:
Andrew Dunstan wrote:
It's not. If we really want to tackle this root and branch without
upsetting legacy code, I think we'd need to have a way of marking
data items as binary in the grammar, e.g.
create function myfunc(myarg binary bytea) returns binary bytea
Andrew Dunstan wrote:
It's not. If we really want to tackle this root and branch without
upsetting legacy code, I think we'd need to have a way of marking
data items as binary in the grammar, e.g.
create function myfunc(myarg binary bytea) returns binary bytea
language plperl as $$ ...$$;
Hiroshi Inoue wrote:
Hiroshi Inoue wrote:
User Petere wrote:
Log Message:
---
Put Autotools-generated files into subdirectory config/; add macro
files used from PostgreSQL there so you don't need a PostgreSQL
source tree to bootstrap the code.
snip
Added Files:
Jim Nasby wrote:
On May 5, 2007, at 10:38 AM, Neil Conway wrote:
On Sat, 2007-05-05 at 11:03 -0400, Tom Lane wrote:
I'm not necessarily opposed to changing the default configure
selection,
but I am opposed to removing the FP code entirely.
I would be satisfied with changing the
I wrote:
OK, summarising what looks to me like a consensus position, ISTM the
plan could be:
. fix makeArrayTypeName() or similar to make it try harder to generate
a unique non-clashing name
. remove the existing 62 instead of 63 name length restrictions
. autogenerate array types for
On Sun, May 06, 2007 at 01:33:47PM -0400, Andrew Dunstan wrote:
However, there are still some oddities. For example, a change to or
removal of the base type affects the array type, but the array type
can be directly operated on (e.g. alter type _aa set schema foo ).
I'm inclined to say we
On Sun, 2007-06-05 at 13:09 -0400, Bruce Momjian wrote:
Also, are we sure we can load a dump that used the float format? What
happens for a date out of int8 range?
AFAIK we should always be able to reload timestamp values that are in
the legal range for an int8-based timestamp. For values
Peter Eisentraut wrote:
Hiroshi Inoue wrote:
Hiroshi Inoue wrote:
User Petere wrote:
Log Message:
---
Put Autotools-generated files into subdirectory config/; add macro
files used from PostgreSQL there so you don't need a PostgreSQL
source tree to bootstrap the code.
snip
Added
Andrew Dunstan [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
This ought to be a property of data type plus language, not a property
of a function.
Why should it?
And how would you do it in such a way that it didn't break legacy code?
My GUC proposal would have made it language+type
Jim Nasby [EMAIL PROTECTED] writes:
Also, what would be the appropriate way to put this into initdb?
You seem to have missed a step here, which is to convince people that
these belong in core at all. So far I've not even seen an argument that
would justify putting them in contrib. If they
Neil Conway [EMAIL PROTECTED] writes:
On Thu, 2007-26-04 at 18:07 -0400, Neil Conway wrote:
(1) I believe the reasoning for Tom's earlier change was not to reduce
the I/O between the backend and the pgstat process [...]
Tom, any comments on this? Your change introduced an undocumented
Jim Nasby wrote:
If we really want to make the logfile the approved method for
monitoring performance, then why do we have the stats infrastructure
at all? It could all be replaced with logging output and pgfouine.
First we'd have to fix the usability problem of our redirect_stderr
stuff
Alvaro Herrera [EMAIL PROTECTED] wrote:
ITAGAKI Takahiro wrote:
I found that autovacuum launcher does not launch any workers in HEAD.
The attached autovacuum-fix.patch could fix the problem. I changed
to use 'greater or equal' instead of 'greater' at the decision of
next autovacuum
What we've basically got here is a complaint that the default
textual-representation-based method for transmitting PL function
parameters and results is awkward and inefficient for bytea.
So the first question is whether this is really localized to only
bytea, and if not which other types have
Hello, I have a system where there are mostly COPYs,
which insert data into a table. Ocasionally a COPY will fail (and thus,
dead rows appear), but as far as I can tell ROLLBACK is not reflected
anywhere in the pg_stats_user_tables. And since there are no rows
n_tup_upd or n_tup_del, therefore
21 matches
Mail list logo
