On Aug 6, 2010, at 10:49 PM, Pavel Stehule wrote:
Huh? You can select into an array:
and pg doesn't handle 2D arrays well - can't to use ARRAY(subselect)
constructor for 2D arrays
Right.
try=# select ARRAY(SELECT ARRAY[k,v] FROM foo);
ERROR: could not find array type for datatype text[]
On Fri, 6 Aug 2010, James William Pye wrote:
On Aug 6, 2010, at 4:31 PM, Kris Jurka wrote:
binary-copy-end-v2.patch
I think there's a snag in the patch:
postgres=# COPY data FROM '/Users/jwp/DATA.bcopy' WITH BINARY;
ERROR: row field count is -1, expected 1
CONTEXT: COPY data, line 4
2010/8/7 David E. Wheeler da...@kineticode.com:
On Aug 6, 2010, at 10:49 PM, Pavel Stehule wrote:
Huh? You can select into an array:
and pg doesn't handle 2D arrays well - can't to use ARRAY(subselect)
constructor for 2D arrays
Right.
try=# select ARRAY(SELECT ARRAY[k,v] FROM foo);
On 07/08/10 07:43, Gordon Shannon wrote:
Regarding HOT prune, I never did any updates, so I think there couldn't be
any HOT tuples. Or does HOT prune do more than that?
Yes, HOT will also prune away DELETEd tuples. It will leave behind a
dead line pointer, so it won't stop the table from
On 8/5/2010 9:44 PM, Merlin Moncure wrote:
On Thu, Aug 5, 2010 at 2:09 PM, Tom Lanet...@sss.pgh.pa.us wrote:
I was not persuaded that there's a real bug in practice. IMO, his
problem was a broken trigger not broken upsert logic. Even if we
conclude this is unsafe, simply removing the example
On 8/6/2010 10:49 AM, Dean Rasheed wrote:
On 4 August 2010 15:08, Marko Tiikkajamarko.tiikk...@cs.helsinki.fi wrote:
I'm mainly concerned about concurrently running transactions.
Once again, I think I mis-understood your point. I think that the
database can't really lock anything before
Hello
2010/8/7 Itagaki Takahiro itagaki.takah...@gmail.com:
2010/7/26 Robert Haas robertmh...@gmail.com:
Come to think of it, have we checked that the behavior of LEFT, RIGHT,
REVERSE, etc. is the same on other DBs, especially as far as nulls,
empty strings, too-large or negative subscripts,
I wrote:
1. The use of rd_amcache is very questionable.
Attached is an alternate patch that I think you should give serious
consideration to. The basic idea here is to only update the metapage
stats data during VACUUM, and not bother with incremental updates during
other operations. That gets
On 06/08/10 20:55, Peter Eisentraut wrote:
On fre, 2010-08-06 at 09:04 +0100, Mike Fowler wrote:
If the patch is to be committed, does it make sense for me to refine
it such that it uses the new xpath internal function you extracted in
the xmlexists patch?
Yes, you can probably shrink this
On 06/08/10 21:55, Peter Eisentraut wrote:
On fre, 2010-08-06 at 14:43 +0100, Mike Fowler wrote:
Or perhaps it could return a string instead of a boolean: content,
document, or NULL if it's neither.
I like the sound of that. In fact this helps workaround the IS
DOCUMENT
and IS CONTENT
I notice that there are many spam messages coming through on Committers.
That seems a little strange, since one of my commit messages has been
held for moderator approval. (Apparently the word sub just happened to
get wrapped into first byte position, and so has been confused with a
subscribe
In this case, was it email From @news.postgresql.org to @postgresql.org?
If so, this is already been corrected ...
On Fri, 6 Aug 2010, Simon Riggs wrote:
I notice that there are many spam messages coming through on Committers.
That seems a little strange, since one of my commit messages
Itagaki Takahiro itagaki.takah...@gmail.com writes:
Accessor functions to get so far collected statistics for the current
transaction
https://commitfest.postgresql.org/action/patch_view?id=301
The latest version of the patch works as expected, and also well-formed.
I'll mark the patch to
I think this simple test highlights the question well.
--
create temporary table t(x int) with (autovacuum_enabled=off);
insert into t select x from generate_series(1,1,1)x;
vacuum verbose t;
select dead_tuple_count from pgstattuple('t');-- 0
delete from t where x = 100;
Do we have a projected data for the next 9.0 wrap, and will it be
beta5 or rc1? How much should we worry about the remaining open
items?
http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items
I am inclined to say that all three of the items currently on the list
need to be addressed in some
On Sat, Aug 7, 2010 at 20:13, Robert Haas robertmh...@gmail.com wrote:
Do we have a projected data for the next 9.0 wrap, and will it be
beta5 or rc1? How much should we worry about the remaining open
items?
If we are taking a vote, I +1 for rc1 :).
On Aug 7, 2010, at 12:24 AM, Pavel Stehule wrote:
try=# create or replace function try(bool) returns text language plperl AS
'shift';
CREATE FUNCTION
Time: 121.403 ms
try=# select try(true);
try
-
t
(1 row)
I wish this wasn't so.
It must not be - it depends on PL handler
17 matches
Mail list logo
