On 27/01/11 00:40, Peter Eisentraut wrote:
> On tor, 2011-01-20 at 03:16 +0100, Jan Urbański wrote:
>> Here's an updated patch series for PL/Python refactoring. It was 16
>> patches at first, 8 are committed, 1 got dropped, so we're down to 7.
>
> Everything(*) is now committed.
Great, thanks.
I
On tor, 2011-01-20 at 03:16 +0100, Jan Urbański wrote:
> Here's an updated patch series for PL/Python refactoring. It was 16
> patches at first, 8 are committed, 1 got dropped, so we're down to 7.
Everything(*) is now committed.
In 0006-Improve-exception-usage-in-PL-Python.patch I went for TypeEr
On 22/01/11 21:53, Peter Eisentraut wrote:
> On tor, 2011-01-20 at 03:16 +0100, Jan Urbański wrote:
>> Here's an updated patch series for PL/Python refactoring. It was 16
>> patches at first, 8 are committed, 1 got dropped, so we're down to 7.
>
>> Refactor PLy_spi_prepare to save two levels of in
On tor, 2011-01-20 at 03:16 +0100, Jan Urbański wrote:
> Here's an updated patch series for PL/Python refactoring. It was 16
> patches at first, 8 are committed, 1 got dropped, so we're down to 7.
> Refactor PLy_spi_prepare to save two levels of indentation.
>
> Instead of checking if the arglist
On ons, 2011-01-19 at 10:06 +0900, Hitoshi Harada wrote:
> - This is not in the patch, but around line 184 "vis versa" in comment
> seems like typo.
Fixed.
> - A line break should be added before PLy_add_exception() after "static void"
I'll add that when I get to the patch.
> - This is also not
On 20/01/11 01:26, Jan Urbański wrote:
> On 19/01/11 10:57, Jan Urbański wrote:
>> On 18/01/11 23:22, Peter Eisentraut wrote:
>>> #2: It looks like this loses some information/formatting in the error
>>> message. Should we keep the pointing arrow there?
>
>>> CONTEXT: PL/Python function "sql_sy
On 19/01/11 10:57, Jan Urbański wrote:
> On 18/01/11 23:22, Peter Eisentraut wrote:
>> #2: It looks like this loses some information/formatting in the error
>> message. Should we keep the pointing arrow there?
>> CONTEXT: PL/Python function "sql_syntax_error"
>> -ERROR: syntax error at or near
On Wed, Jan 19, 2011 at 2:59 PM, Peter Eisentraut wrote:
> On ons, 2011-01-19 at 00:52 -0300, Alvaro Herrera wrote:
>> Excerpts from Peter Eisentraut's message of mar ene 18 19:22:50 -0300 2011:
>>
>> > #16: This is probably pointless because pgindent will reformat this.
>>
>> pgindent used to rem
On ons, 2011-01-19 at 00:52 -0300, Alvaro Herrera wrote:
> Excerpts from Peter Eisentraut's message of mar ene 18 19:22:50 -0300 2011:
>
> > #16: This is probably pointless because pgindent will reformat this.
>
> pgindent used to remove useless braces around single-statement blocks,
> but this b
Alvaro Herrera writes:
> Excerpts from Peter Eisentraut's message of mar ene 18 19:22:50 -0300 2011:
>> #16: This is probably pointless because pgindent will reformat this.
> pgindent used to remove useless braces around single-statement blocks,
> but this behavior was removed years ago because i
On 19/01/11 16:35, David Fetter wrote:
> On Wed, Jan 19, 2011 at 11:09:56AM +0100, Jan Urbański wrote:
>> On 19/01/11 02:06, Hitoshi Harada wrote:
>>> - PLy_(input|output)_tuple_funcs() in PLy_trigger_handler() is added.
>>> The comment says it should check for the possibility that the
>>> relation
On Wed, Jan 19, 2011 at 11:09:56AM +0100, Jan Urbański wrote:
> On 19/01/11 02:06, Hitoshi Harada wrote:
> > 2011/1/19 Peter Eisentraut :
> >> On mån, 2011-01-17 at 21:49 +0200, Peter Eisentraut wrote:
> >>> On sön, 2011-01-02 at 12:41 +0100, Jan Urbański wrote:
> Here they are. There are 16 p
2011/1/19 Jan Urbański :
> On 19/01/11 02:06, Hitoshi Harada wrote:
>> - -1 is used as the initial value of PLyTypeInfo.is_rowtype. Why not 0?
>
> See the comments in struct PLyTypeInfo:
>
> is_rowtype can be: -1 = not known yet (initial state); 0 = scalar
> datatype; 1 = rowtype; 2 = rowtype, but
On 19/01/11 02:06, Hitoshi Harada wrote:
> 2011/1/19 Peter Eisentraut :
>> On mån, 2011-01-17 at 21:49 +0200, Peter Eisentraut wrote:
>>> On sön, 2011-01-02 at 12:41 +0100, Jan Urbański wrote:
Here they are. There are 16 patches in total. They amount to what's
currently in my refactor bra
On 18/01/11 23:22, Peter Eisentraut wrote:
> On mån, 2011-01-17 at 21:49 +0200, Peter Eisentraut wrote:
>> On sön, 2011-01-02 at 12:41 +0100, Jan Urbański wrote:
>>> Here they are. There are 16 patches in total. They amount to what's
>>> currently in my refactor branch (and almost to what I've sent
Excerpts from Peter Eisentraut's message of mar ene 18 19:22:50 -0300 2011:
> #16: This is probably pointless because pgindent will reformat this.
pgindent used to remove useless braces around single-statement blocks,
but this behavior was removed years ago because it'd break formatting
around PG
2011/1/19 Peter Eisentraut :
> On mån, 2011-01-17 at 21:49 +0200, Peter Eisentraut wrote:
>> On sön, 2011-01-02 at 12:41 +0100, Jan Urbański wrote:
>> > Here they are. There are 16 patches in total. They amount to what's
>> > currently in my refactor branch (and almost to what I've sent as the
>> >
On mån, 2011-01-17 at 21:49 +0200, Peter Eisentraut wrote:
> On sön, 2011-01-02 at 12:41 +0100, Jan Urbański wrote:
> > Here they are. There are 16 patches in total. They amount to what's
> > currently in my refactor branch (and almost to what I've sent as the
> > complete refactor patch, while doi
On sön, 2011-01-02 at 12:41 +0100, Jan Urbański wrote:
> Here they are. There are 16 patches in total. They amount to what's
> currently in my refactor branch (and almost to what I've sent as the
> complete refactor patch, while doing the splitting I discovered a few
> useless hunks that I've disca
On lör, 2011-01-01 at 13:24 +0100, Jan Urbański wrote:
> On 01/01/11 01:00, Peter Eisentraut wrote:
> > On tor, 2010-12-23 at 14:41 +0100, Jan Urbański wrote:
> >> It does some architectural changes to PL/Python that make it easier to
> >> implement other features, like for instance a validator fun
On 01/01/11 01:00, Peter Eisentraut wrote:
> On tor, 2010-12-23 at 14:41 +0100, Jan Urbański wrote:
>> It does some architectural changes to PL/Python that make it easier to
>> implement other features, like for instance a validator function. The
>> full list of changes in the patch is:
>
> I woul
On tor, 2010-12-23 at 14:41 +0100, Jan Urbański wrote:
> It does some architectural changes to PL/Python that make it easier to
> implement other features, like for instance a validator function. The
> full list of changes in the patch is:
I would review this and the following patches, but I'd rea
22 matches
Mail list logo
