2010/8/8 David E. Wheeler :
> 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 th
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 - i
On Sat, Aug 7, 2010 at 20:13, Robert Haas 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 :).
> http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items
>
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 w
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;
Itagaki Takahiro 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 "Ready for Committer".
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 ha
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 m
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 limitat
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 pat
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
Hello
2010/8/7 Itagaki Takahiro :
> 2010/7/26 Robert Haas :
>> 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, etc is concerned? Is
>> CONCAT('foo', NU
On 8/6/2010 10:49 AM, Dean Rasheed wrote:
On 4 August 2010 15:08, Marko Tiikkaja 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 firing the trigger because
the vie
On 8/5/2010 9:44 PM, Merlin Moncure wrote:
On Thu, Aug 5, 2010 at 2:09 PM, Tom Lane 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 is of no help to
a
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 grow
2010/8/7 David E. Wheeler :
> 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
On Fri, 6 Aug 2010, James William Pye wrote:
On Aug 6, 2010, at 4:31 PM, Kris Jurka wrote:
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
Probably a quick/small fix
17 matches
Mail list logo