2010/7/13 Pavel Stehule :
> so this is actualised patch:
> * concat_sql removed
> * left, right, reverse and concat are in core
> * printf and concat_ws are in contrib
> * format show "" as NULL string
> * removed an using of wide chars
I think function codes in the core (concat, format, left, rig
I think the patch is almost ready for committer except the following
three issues:
2010/7/13 Fujii Masao :
>> + if (!*value || *endptr || file_mode < 0 || file_mode > 0777)
> The sticky bit cannot be set via log_file_mode. Is this intentional?
We should also check the value not to be somethin
Andrew Dunstan writes:
> Tom Lane wrote:
>> What this looks like to me is that dblink.c doesn't contain the fix
>> that the new regression test is checking for.
>>
>> pangolin is pulling from the git mirror, which I still don't trust
>> further than I can throw it. How about you?
> There is som
Tom Lane wrote:
Itagaki Takahiro writes:
I found regression test for dblink in HEAD was failed on my machine.
One buildfarm machine also reported the same failure.
What this looks like to me is that dblink.c doesn't contain the fix
that the new regression test is checking for.
pang
Excerpts from Tom Lane's message of lun jul 12 23:02:05 -0400 2010:
> pangolin is pulling from the git mirror, which I still don't trust
> further than I can throw it. How about you?
Easy enough to check -- just verify the $PostgreSQL$ tag in the file.
Oh wait ...
--
Sent via pgsql-hackers ma
Itagaki Takahiro writes:
> I found regression test for dblink in HEAD was failed on my machine.
> One buildfarm machine also reported the same failure.
What this looks like to me is that dblink.c doesn't contain the fix
that the new regression test is checking for.
pangolin is pulling from the g
I found regression test for dblink in HEAD was failed on my machine.
One buildfarm machine also reported the same failure.
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=pangolin&dt=2010-07-12%2013:37:06
It seems to come from the recent fix for dropped column support,
but I'm not sure why
On Mon, Jul 12, 2010 at 7:36 PM, Martin Pihlak wrote:
> Itagaki Takahiro wrote:
>> I checked "log_file_mode GUC" patch, and found a couple of Windows-specific
>> and translation issues.
>
> Thank you for the review. Attached patch attempts to fix these issues.
> + if (!*value || *endptr || fi
Greg Smith writes:
> Tom Lane wrote:
>> Is there a specific period when that's supposed to happen for GSoC
>> students? Can we arrange for a commitfest to be running then
> The GSoC "Community bonding period" is described at
> http://googlesummerofcode.blogspot.com/2007/04/so-what-is-this-commu
Currently, the recursion in ExplainNode() goes to some lengths to chase
down the PlanState and Plan trees independently. This is a bit silly:
we could just chase the PlanState tree, and use each PlanState's "plan"
link when we needed to get to the matching Plan node. I think this is a
holdover fr
Tom Lane wrote:
Is there a specific period when that's supposed to happen for GSoC
students? Can we arrange for a commitfest to be running then
The GSoC "Community bonding period" is described at
http://googlesummerofcode.blogspot.com/2007/04/so-what-is-this-community-bonding-all.html
and wh
On Jul 12, 2010, at 4:16 PM, Greg Smith wrote:
> I feel the assumption that code is so valuable that it should be shared
> regardless of whether it meets conventions is a flawed one for this project.
> There are already dozens, if not hundreds, of useful patch submissions that
> have been sent
Greg Smith writes:
> There is a brief "get to know the community" period at the beginning of
> the summer schedule. I think that next year this project would be well
> served to give each student a small patch to review during that time, as
> a formal intro to the community process. The tende
Peter Eisentraut wrote:
I think it's better to share code that doesn't mean project guidelines
and solicit advice rather than not to share anything.
I feel the assumption that code is so valuable that it should be shared
regardless of whether it meets conventions is a flawed one for this
p
Hello
so this is actualised patch:
* concat_sql removed
* left, right, reverse and concat are in core
* printf and concat_ws are in contrib
* format show "" as NULL string
* removed an using of wide chars
todo:
NULL handling for printf function
Query:
what is corect result for
* printf(">>%3.
On Mon, 2010-07-12 at 23:28 +0300, Peter Eisentraut wrote:
> On mån, 2010-07-12 at 10:04 -0400, Greg Smith wrote:
> > Wasting the time of everyone in the community by sharing code that
> > doesn't mean any of the project guidelines is a very bad idea; please
> > don't do that again.
>
> I think
On mån, 2010-07-12 at 10:04 -0400, Greg Smith wrote:
> Wasting the time of everyone in the community by sharing code that
> doesn't mean any of the project guidelines is a very bad idea; please
> don't do that again.
I think it's better to share code that doesn't mean project guidelines
and soli
Tom Lane wrote:
Please choose a way that doesn't introduce new portability assumptions.
The backend gets along fine without strtoll, and I don't see why pgbench
should have to require it.
Funny you should mention this...it turns out there is some code already
there, I just didn't notice it
On 7/12/10 9:34 PM +0300, Tom Lane wrote:
Marko Tiikkaja writes:
... So what I'm now thinking of is making the planner plan that as a single
Query, and make the planner expand it into multiple PlannedStmts if
necessary. This would break the existing planner hooks, but I don't
think that's a hu
Marko Tiikkaja writes:
> ... So what I'm now thinking of is making the planner plan that as a single
> Query, and make the planner expand it into multiple PlannedStmts if
> necessary. This would break the existing planner hooks, but I don't
> think that's a huge problem. Does anyone see any o
On 7/12/10 9:07 PM +0300, I wrote:
Consider:
WITH t AS (SELECT 1),
t2 AS (SELECT * FROM t2)
VALUES (true);
That should of course have been SELECT * FROM t, not t2.
Regards,
Marko Tiikkaja
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your s
Hi,
I've been working on writeable CTEs during the last couple of months,
but right now it looks like I'm going to miss the first commit fest for
9.1. I was trying to make it work by expanding all wCTEs to their own
Queries during the rewrite stage (a very crude patch trying to do that
for
2010/7/12 Kevin Grittner :
> Itagaki Takahiro wrote:
>
>> I'd like to move all proposed functions into the core, and not to
>> add contrib/stringfunc.
>
>> Still failed :-( I used UTF8 database with *locale=C* on 64bit
>> Linux.
>> char2wchar() doesn't seem to work on C locale. We should avoid
>>
Itagaki Takahiro wrote:
> I'd like to move all proposed functions into the core, and not to
> add contrib/stringfunc.
> Still failed :-( I used UTF8 database with *locale=C* on 64bit
> Linux.
> char2wchar() doesn't seem to work on C locale. We should avoid
> using the function and converting
Pavel Baroš wrote:
> Dne 9.7.2010 21:33, Robert Haas napsal(a):
>> Please add your patch here, so that it will be reviewed during
>> the about-to-begin CommitFest.
>>
>> https://commitfest.postgresql.org/action/commitfest_view/open
>>
>
> OK, but will you help me with that form? Do you think I c
Dne 9.7.2010 21:33, Robert Haas napsal(a):
2010/7/8 Pavel Baroš:
Description of patch:
1) can create MV, and is created uninitialized with data
CREATE MATERIALIZED VIEW mvname AS SELECT ...
This doesn't seem acceptable. It should populate it on creation.
Yes, it would be better, in addi
Dne 9.7.2010 21:33, Robert Haas napsal(a):
2010/7/8 Pavel Baroš:
Description of patch:
1) can create MV, and is created uninitialized with data
CREATE MATERIALIZED VIEW mvname AS SELECT ...
This doesn't seem acceptable. It should populate it on creation.
Yes, it would be better, in addi
Boxuan Zhai wrote:
I found that people have problems on running my codes, which probably
comes from my nonstandard submission format. I can compile, install
and initialize postgres in my own machine. The system accepts MERGE
command and will throw an error when it runs into the executor, which
Folks,
The PostgreSQL 9.1 Development Plan:
http://wiki.postgresql.org/wiki/PostgreSQL_9.1_Development_Plan
calls for a CommitFest to run from the 15th of July until the 15th
of August. I've offered to manage the CF process this time around.
(Selena, are you up for continuing to work on thi
On Jul 11, 2010, at 10:32 PM, Itagaki Takahiro
wrote:
> 2010/7/12 Robert Haas :
>> I'm all in favor of putting such things in core as are supported by
>> multiple competing products, but is that really true for all of these?
>
> - concat() : MySQL, Oracle, DB2
> - concat_ws() : MySQL,
> - left()
On 12 July 2010 13:07, Mike Fowler wrote:
> Thom Brown wrote:
>>
>> Just wondering about that semi-colon after the namespace definition.
>>
>> Thom
>>
>
> The semi-colon is not supposed to be there, and I'm not sure where it's come
> from. With Thunderbird I see the email with my patch as an attac
Thom Brown wrote:
Would a test for mismatched or undefined namespaces be necessary?
For example:
Mismatched namespace:
http://postgresql.org/stuff";>bar
Undefined namespace when used in conjunction with IS DOCUMENT:
http://postgresql.org/stuff";>bar
Thanks for looking at my patch Thom. I
Itagaki Takahiro wrote:
> I checked "log_file_mode GUC" patch, and found a couple of Windows-specific
> and translation issues.
Thank you for the review. Attached patch attempts to fix these issues.
> * fchmod() is not available on some platforms, including Windows.
> fh = fopen(filename, mod
On Sun, Jul 11, 2010 at 00:05, Peter Eisentraut wrote:
> On lör, 2010-07-10 at 16:23 -0400, Bruce Momjian wrote:
>> Wow, how would they know if the binaries are MinGW compiled? Does it
>> show in version()?
>
> Yes, I think so.
It definitely does.
--
Magnus Hagander
Me: http://www.hagander.n
On Mon, Jul 12, 2010 at 11:36, Itagaki Takahiro
wrote:
> "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 p
"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".
http://archives.postgresql.org/messa
Hello
2010/7/12 Robert Haas :
> On Sun, Jul 11, 2010 at 10:30 PM, Itagaki Takahiro
> wrote:
>> 2010/7/9 Pavel Stehule :
>>> I am sending a actualised patch
>>> * removed concat_json
>>> * renamed function rvsr to reverse
>>> * functions format, sprintf and concat* are stable now (as to_char for
On 10 July 2010 14:12, Mike Fowler wrote:
> Robert Haas wrote:
>>
>> On Fri, Jul 9, 2010 at 4:06 PM, Peter Eisentraut wrote:
>>
>>>
>>> On ons, 2010-07-07 at 16:37 +0100, Mike Fowler wrote:
>>>
Here's the patch to add the 'xml_is_well_formed' function.
>>>
>>> I suppose we should r
2010/7/12 Itagaki Takahiro :
> 2010/7/12 Pavel Stehule :
>> I prefere a new names - because there are a new behave - with little
>> bit better default handling of NULL values. string_to_array and
>> array_to_string just ignore NULL values - what isn't correct behave.
>> Later we can mark these fun
(1) Exclusion constraints support for operators where "x x"
is false (tiny patch)
https://commitfest.postgresql.org/action/patch_view?id=307
(2) btree_gist support for searching on <> ("not equals")
https://commitfest.postgresql.org/action/patch_view?id=308
Those patches should be committed at on
some note
2010/7/12 Pavel Stehule :
> 2010/7/12 Itagaki Takahiro :
>> https://commitfest.postgresql.org/action/patch_view?id=300
>>
>> Why did you add to_string() and to_array() functions though we already
>> have string_to_array() and array_to_string() functions? I prefer adding
>> three argumen
2010/7/12 Pavel Stehule :
> I prefere a new names - because there are a new behave - with little
> bit better default handling of NULL values. string_to_array and
> array_to_string just ignore NULL values - what isn't correct behave.
> Later we can mark these functions as deprecated and remove it.
2010/7/12 Tom Lane :
> Itagaki Takahiro writes:
>> 2010/7/8 Tom Lane :
>>> For example, the dictionary-load code could automatically execute
>>> the precompile step if it observed that the precompiled copy of the
>>> dictionary was missing or had an older file timestamp than the source.
I am not
43 matches
Mail list logo
