On Mon, Jan 24, 2011 at 4:47 PM, Magnus Hagander mag...@hagander.net wrote:
On Mon, Jan 24, 2011 at 08:45, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Jan 21, 2011 at 12:28 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
- Why not initialize logid and
On Sat, Jan 22, 2011 at 07:20, Tom Lane t...@sss.pgh.pa.us wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
* I wonder if CREATE FOREIGN DATA WRAPPER should automatically create
the handler function, if it doesn't exist yet.
Doing that would require the equivalent of
2011/1/24 Stephen Frost sfr...@snowman.net:
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
I merge your changes and little enhanced comments.
Thanks. Reviewing this further-
Why are you using 'FOREACH' here instead of just making it another
variation of 'FOR'? What is 'FOUND'
Robert Haas robertmh...@gmail.com writes:
On Sun, Jan 23, 2011 at 9:20 PM, Joseph Adams
joeyadams3.14...@gmail.com wrote:
The attached patch changes hstore's Makefile so it is like the others.
Thanks, committed.
For the record, I smell bitrot here:
On 01/23/2011 11:11 PM, Xiaobo Gu wrote:
Yes, I want it working on 64 bit Windows Server 2003 R2 and 64 bit
Windows 7 home basic.
Which version of 32bit MinGW do you use, I use the one shipped with
Rtools212.exe which is downloaded from
http://www.murdoch-sutherland.com/Rtools, and there is
On 24/01/11 02:01, Nate C wrote:
Unexpected argument handling in pl/python variadic argument function
create or replace function variadic_sql
(template text, variadic args text[], out text)
language sql as
$$
select $1 || ' -- ' || $2::text
$$;
On Wed, Jan 19, 2011 at 14:36, Stephen Frost sfr...@snowman.net wrote:
Alright, here's the latest on this patch. I've added a log_csv_fields
GUC along with the associated magic to make it work (at least for me).
Also added 'role_name' and '%U' options. Requires postmaster restart to
change,
Hello
Other comments- I don't like using 'i' and 'j', you really should use
better variable names, especially in large loops which contain other
loops. I'd also suggest changing the outer loop to be equivilant to the
number of iterations that will be done instead of the number of items
2011/1/24 Pavel Stehule pavel.steh...@gmail.com:
Hello
Other comments- I don't like using 'i' and 'j', you really should use
better variable names, especially in large loops which contain other
loops. I'd also suggest changing the outer loop to be equivilant to the
number of iterations
On Mon, Jan 24, 2011 at 2:45 AM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
[ latest patch ]
I notice that this is adding keywords and syntax support for what is
basically a PostgreSQL extension (since we certainly can't possibly be
following the SQL standards given that we're not
On Mon, Jan 24, 2011 at 20:49, Robert Haas robertmh...@gmail.com wrote:
I notice that this is adding keywords and syntax support for what is
basically a PostgreSQL extension (since we certainly can't possibly be
following the SQL standards given that we're not implementing a new
datatype. Is
Hello
I see that the gist README file (src/backend/access/gist/README) hasn't
seen any major content updates, since its initial creation, apart from
gist insertion recovery issues [1].
I would like to ask if there are any major differences between the
README file and postrges' code, and if
On 21.01.2011 17:57, Robert Haas wrote:
On Fri, Jan 21, 2011 at 10:17 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 18.01.2011 17:26, Shigeru HANADA wrote:
1) 20110118-no_fdw_perm_check.patch - This patch is not included in
last post. This had been proposed on
On Mon, Jan 24, 2011 at 8:08 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
* Is there any point in allowing a FDW without a handler? It's totally
useless, isn't it? We had the CREATE FOREIGN DATA WRAPPER syntax in previous
versions, and it allowed it, but it has always been
Hello
I see that the gist README file (src/backend/access/gist/README) hasn't
seen any major content updates, since its initial creation, apart from
gist insertion recovery issues [1].
I would like to ask if there are any major differences between the
README file and postrges' code, and if
Hi,
According to http://www.pgbuildfarm.org/cgi-bin/show_status.pl, only
GCC 3.4.2 and 4.5.0 have successfully build PostgreSQL,and only under
32 bit Windows environment, and I guess from
http://archives.postgresql.org/pgsql-hackers/2010-12/msg02073.php that
you mean we should only the above two
On Mon, Jan 24, 2011 at 6:58 AM, Vangelis Katsikaros
vkatsika...@yahoo.gr wrote:
I see that the gist README file (src/backend/access/gist/README) hasn't seen
any major content updates, since its initial creation, apart from gist
insertion recovery issues [1].
I would like to ask if there are
On 01/24/2011 02:25 PM, Vangelis Katsikaros wrote:
[skip]
Oh sorry for the double posting. Thought I canceled it, my bad...
Vangelis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
On 24.01.2011 03:42, Itagaki Takahiro wrote:
To suppress it, I'm thinking to add noreturn to die_horribly().
Any objections? Another solution might be adding a dummy assignment
after calls of die_horribly().
I added a dummy
On Mon, Jan 24, 2011 at 09:03, Fujii Masao masao.fu...@gmail.com wrote:
On Mon, Jan 24, 2011 at 4:47 PM, Magnus Hagander mag...@hagander.net wrote:
On Mon, Jan 24, 2011 at 08:45, Fujii Masao masao.fu...@gmail.com wrote:
On Fri, Jan 21, 2011 at 12:28 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Hi!
On Mon, Jan 24, 2011 at 3:07 AM, Jan Urbański wulc...@wulczer.org wrote:
I see two issues with this patch. First of them is the resulting index
size. I created a table with 5 copies of
/usr/share/dict/american-english in it and a gin index on it, using
gin_trgm_ops. The results were:
On 2011-01-24 16:34, Alexander Korotkov wrote:
Hi!
On Mon, Jan 24, 2011 at 3:07 AM, Jan Urbańskiwulc...@wulczer.org wrote:
I see two issues with this patch. First of them is the resulting index
size. I created a table with 5 copies of
/usr/share/dict/american-english in it and a gin index on
On 13.01.2011 23:32, Heikki Linnakangas wrote:
Anyway, here's an updated patch with all the known issues fixed.
Another updated patch. Fixed bitrot, and addressed the privilege issue
Fujii-san raised here:
http://archives.postgresql.org/message-id/4d380560.3040...@enterprisedb.com.
I
Florian Pflug f...@phlo.org writes:
On Jan22, 2011, at 17:55 , Tom Lane wrote:
Reflecting on that, I'm inclined to suggest
Bitmap Heap Scan ...
Recheck Cond: blah blah
Rows Removed by Recheck Cond: 42
Filter Cond: blah blah blah
Rows
si...@2ndquadrant.com (Simon Riggs) writes:
I just wanted to point out that the patch submitted here does not allow
what is requested here for FKs (nor indexes).
That's fine; I was trying to support the thought that there was
something useful about this idea. Being able to expressly deactivate
Jesper Krogh jes...@krogh.cc writes:
Would it be hard to make it support n-grams (e.g. making the length
configurable) instead of trigrams?
That would be a complete rewrite with an incompatible on-disk index
representation, which seems a bit beyond the scope of this patch.
Steve Singer ssinger...@sympatico.ca writes:
src/backend/parser/parse_utilcmd.c: 1452
Your calling strdup on the attribute name. I don't have a good enough
grasp on the code to be able to trace this through to where the memory
gets free'd. Does it get freed? Should/could this be a call to
On Mon, Jan 24, 2011 at 17:52, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 13.01.2011 23:32, Heikki Linnakangas wrote:
Anyway, here's an updated patch with all the known issues fixed.
Another updated patch. Fixed bitrot, and addressed the privilege issue
Fujii-san raised
Robert Haas robertmh...@gmail.com wrote:
I am wondering if it wouldn't be simpler and more logical to allow
idempotent changes of these settings at any time, and to restrict
only changes that actually change something. It feels really
weird to allow changing these properties to their own
On Thu, Jan 13, 2011 at 2:40 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Jan 13, 2011 at 4:24 PM, Fujii Masao masao.fu...@gmail.com wrote:
So I'm thinking to change pg_last_xlog_receive_location not to
move backwards.
The attached patch does that.
It looks to me like this is
On Mon, Jan 24, 2011 at 2:21 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Robert Haas robertmh...@gmail.com wrote:
I am wondering if it wouldn't be simpler and more logical to allow
idempotent changes of these settings at any time, and to restrict
only changes that actually change
On 24.01.2011 20:22, Magnus Hagander wrote:
On Mon, Jan 24, 2011 at 17:52, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Another updated patch. Fixed bitrot, and addressed the privilege issue
Fujii-san raised here:
PgUS is preparing to fund a grant for PgUS members to learn and
participate in the patch review process. We looking for experienced
reviewers that can assist a candidate through to process of testing a
patch - to submitting the final review. The ultimate deliverable
would be the actual review
On Mon, Jan 24, 2011 at 21:14, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 24.01.2011 20:22, Magnus Hagander wrote:
I can't see an explicit check for the user ttempting to do
pg_stop_backup() when there is a nonexclusive backup running? Maybe
I'm reading it wrong? The case
On 24.01.2011 22:31, Magnus Hagander wrote:
On Mon, Jan 24, 2011 at 21:14, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 24.01.2011 20:22, Magnus Hagander wrote:
I can't see an explicit check for the user ttempting to do
pg_stop_backup() when there is a nonexclusive backup
Just to put this on the record for 9.2: I've just thought of a way
to further extend the READ ONLY optimizations to de facto READ ONLY
transactions. Right now, when a dangerous structure is formed with
three transactions (which consists of read-write dependencies from
T0 - T1 - T2) and T2 is
Somehow, pgindent appears to have this approach to push lines that are
longer than the defined line length limit back to the left to make it
fit. That results in something like this:
printfPQExpBuffer(buf,
SELECT n.nspname as \%s\,\n
p.proname AS
I wrote:
... If that's the only issue then I don't see any need to wait on
the author, so will take this one.
I find myself quite dissatisfied with the way that this patch adds yet
another bool flag to index_create (which has too many of those already),
with the effect of causing it to exactly
On Sun, Jan 9, 2011 at 5:03 PM, Noah Misch n...@leadboat.com wrote:
Here I add the notion of an exemptor function, a property of a cast that
determines when calls to the cast would be superfluous. Such calls can be
removed, reduced to RelabelType expressions, or annotated (via a new field in
Greg Smith wrote:
Bruce Momjian wrote:
xlogdefs.h says:
/*
* Because O_DIRECT bypasses the kernel buffers, and because we never
* read those buffers except during crash recovery, it is a win to use
* it in all cases where we sync on each write(). We could allow O_DIRECT
*
Tom Lane wrote:
I wrote:
He's complaining that it dies with EINVAL.
I notice that (1) it's using O_DIRECT even though the printout claims
otherwise, and (2) it's writing from a buffer that has no better than
char alignment, which is certainly not OK for O_DIRECT. Either one
of those
On Mon, Jan 24, 2011 at 7:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
One other issue that might be worthy of discussion is that as things
stand, execution of the ADD CONSTRAINT USING INDEX syntax will cause
the constraint to absorb the index as an INTERNAL dependency. That
means dropping the
On Sat, Jan 22, 2011 at 11:32:02AM +0100, Pavel Stehule wrote:
because I am not sure so any complex solution can be done to deadline
for 9.1, I created a patch that is based on Tom ideas - just
explicitly detoast function parameters.
I can confirm that, for your original test case, this yields
On Sat, Jan 15, 2011 at 06:41, Peter Eisentraut pete...@gmx.net wrote:
I've been going over this patch with a fine-tooth comb for the last two
weeks, fixed some small bugs, added comments, made initdb a little
friendlier, but no substantial changes.
What can I do to test the patch?
No
On Tue, Jan 25, 2011 at 4:25 AM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Jan 13, 2011 at 2:40 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Thu, Jan 13, 2011 at 4:24 PM, Fujii Masao masao.fu...@gmail.com wrote:
So I'm thinking to change pg_last_xlog_receive_location not to
move
On 1/24/11 12:17 PM, Richard Broersma wrote:
PgUS is preparing to fund a grant for PgUS members to learn and
participate in the patch review process. We looking for experienced
reviewers that can assist a candidate through to process of testing a
patch - to submitting the final review. The
On Sat, Jan 15, 2011 at 02:25, Hitoshi Harada umi.tan...@gmail.com wrote:
The patch overrides client_encoding by the added ENCODING option, and
restores it as soon as copy is done.
We cannot do that because error messages should be encoded in the original
encoding even during COPY commands with
On Mon, Jan 24, 2011 at 5:53 PM, Josh Berkus j...@agliodbs.com wrote:
On 1/24/11 12:17 PM, Richard Broersma wrote:
PgUS is preparing to fund a grant for PgUS members to learn and
participate in the patch review process. We looking for experienced
reviewers that can assist a candidate
Peter Eisentraut wrote:
Somehow, pgindent appears to have this approach to push lines that are
longer than the defined line length limit back to the left to make it
fit. That results in something like this:
printfPQExpBuffer(buf,
SELECT n.nspname as \%s\,\n
Bruce Momjian br...@momjian.us writes:
Peter Eisentraut wrote:
Somehow, pgindent appears to have this approach to push lines that are
longer than the defined line length limit back to the left to make it
fit. That results in something like this:
Can we get rid of this behavior?
I think
On Tue, Jan 25, 2011 at 5:14 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I'm not entirely sure the replication privilege removal is correct.
Doing that, it's no longer possible to deploy a slave *without* using
pg_basebackup, unless you are superuser. Do we really want to
On Tue, Jan 25, 2011 at 6:02 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Hmm, perhaps the code would be more readable if instead of the
forcePageWrites counter that counts exclusive and non-exclusive backups, and
an exclusiveBackup boolean indicating if one of the
On Mon, Jan 24, 2011 at 07:18:47PM -0500, Robert Haas wrote:
On Sun, Jan 9, 2011 at 5:03 PM, Noah Misch n...@leadboat.com wrote:
Here I add the notion of an exemptor function, a property of a cast that
determines when calls to the cast would be superfluous. ?Such calls can be
removed,
Hello
2011/1/25 Noah Misch n...@leadboat.com:
On Sat, Jan 22, 2011 at 11:32:02AM +0100, Pavel Stehule wrote:
because I am not sure so any complex solution can be done to deadline
for 9.1, I created a patch that is based on Tom ideas - just
explicitly detoast function parameters.
I can
On 25.01.2011 06:29, Pavel Stehule wrote:
2011/1/25 Noah Mischn...@leadboat.com:
On Sat, Jan 22, 2011 at 11:32:02AM +0100, Pavel Stehule wrote:
because I am not sure so any complex solution can be done to deadline
for 9.1, I created a patch that is based on Tom ideas - just
explicitly detoast
55 matches
Mail list logo
