Thank you for committing this patch.
> Applied with some mostly-cosmetic adjustments. I also took the
> liberty of changing some of the error message texts to line up
> more closely with the expanded documentation (eg, use "format
> specifier" not "conversion specifier" because that's the phrase
Kyotaro HORIGUCHI writes:
> [ format-width-20130305.patch ]
Applied with some mostly-cosmetic adjustments. I also took the liberty
of changing some of the error message texts to line up more closely
with the expanded documentation (eg, use "format specifier" not
"conversion specifier" because th
Hello,
> Patches can be reviewed by more than one people. It's particularly
> useful if they have different things to say. So don't hesitate to
> review patches that have already been reviewed by other people.
Thanks for the advice. I was anxious about who among the
reviewers is, and when to ma
Kyotaro HORIGUCHI escribió:
> Umm. sorry,
>
> > If you have no problem with this, I'll send this to committer.
>
> I just found that this patch already has a revewer. I've seen
> only Status field in patch list..
Patches can be reviewed by more than one people. It's particularly
useful if they
2013/3/5 Dean Rasheed :
> On 5 March 2013 13:46, Pavel Stehule wrote:
>> 2013/3/5 Kyotaro HORIGUCHI :
>>> Hello,
>>>
> I think that the only other behavioural glitch I spotted was that it
> fails to catch one overflow case, which should generate an "out of
> ranger" error:
>
>>
On 5 March 2013 13:46, Pavel Stehule wrote:
> 2013/3/5 Kyotaro HORIGUCHI :
>> Hello,
>>
>>> > I think that the only other behavioural glitch I spotted was that it
>>> > fails to catch one overflow case, which should generate an "out of
>>> > ranger" error:
>>> >
>>> > select format('|%*s|', -21474
2013/3/5 Kyotaro HORIGUCHI :
> Hello,
>
>> > I think that the only other behavioural glitch I spotted was that it
>> > fails to catch one overflow case, which should generate an "out of
>> > ranger" error:
>> >
>> > select format('|%*s|', -2147483648, 'foo');
>> > Result: |foo|
>> >
>> > because -(
Hello,
> > I think that the only other behavioural glitch I spotted was that it
> > fails to catch one overflow case, which should generate an "out of
> > ranger" error:
> >
> > select format('|%*s|', -2147483648, 'foo');
> > Result: |foo|
> >
> > because -(-2147483648) = 0 in signed 32-bit integ
Hello
2013/2/28 Dean Rasheed :
> On 28 February 2013 11:25, Kyotaro HORIGUCHI
> wrote:
>> Umm. sorry,
>>
>>> If you have no problem with this, I'll send this to committer.
>>
>> I just found that this patch already has a revewer. I've seen
>> only Status field in patch list..
>>
>> Should I leave
On 28 February 2013 11:25, Kyotaro HORIGUCHI
wrote:
> Umm. sorry,
>
>> If you have no problem with this, I'll send this to committer.
>
> I just found that this patch already has a revewer. I've seen
> only Status field in patch list..
>
> Should I leave this to you, Dean?
>
Sorry, I've been mean
Hello
I have no objections,
Thank you for update
Regards
Pavel
2013/2/28 Kyotaro HORIGUCHI :
> Hello, Could you let me review this patch?
>
>> >> * merged Dean's doc
>> >> * allow NULL as width
>
> I understand that this patch aims pure expansion of format's
> current behavior and to mimic the
Umm. sorry,
> If you have no problem with this, I'll send this to committer.
I just found that this patch already has a revewer. I've seen
only Status field in patch list..
Should I leave this to you, Dean?
--
Kyotaro Horiguchi
NTT Open Source Software Center
--
Sent via pgsql-hackers maili
Hello, Could you let me review this patch?
> >> * merged Dean's doc
> >> * allow NULL as width
I understand that this patch aims pure expansion of format's
current behavior and to mimic the printf in SUS glibc (*1).
(*1) http://pubs.opengroup.org/onlinepubs/009695399/functions/printf.html
This
Hello
2013/2/13 Dean Rasheed :
> On 11 February 2013 14:29, Pavel Stehule wrote:
>> Hello
>>
>> updated patch
>>
>> * merged Dean's doc
>> * allow NULL as width
>>
>
> Hi,
> I have not had time to look at this properly, but it doesn't look as
> though you have fixed the other problem I mentioned
On 11 February 2013 14:29, Pavel Stehule wrote:
> Hello
>
> updated patch
>
> * merged Dean's doc
> * allow NULL as width
>
Hi,
I have not had time to look at this properly, but it doesn't look as
though you have fixed the other problem I mentioned up-thread, with %s
for NULL values:
SELECT form
Hello
updated patch
* merged Dean's doc
* allow NULL as width
Regards
Pavel
2013/2/11 Dean Rasheed :
> On 10 February 2013 12:37, Pavel Stehule >>
> Here is my first draft. I've also attached the generated HTML page,
>>> because it's not so easy to read an SGML patch.
>>>
>>
>> nice
>>
>> I h
On 10 February 2013 12:37, Pavel Stehule >>
Here is my first draft. I've also attached the generated HTML page,
>> because it's not so easy to read an SGML patch.
>>
>
> nice
>
> I have only one point - I am think, so format function should be in
> table 9-6 - some small text with reference to spe
2013/2/10 Dean Rasheed :
> On 9 February 2013 18:30, Pavel Stehule wrote:
> There are a new question
>
> what should be result of
>
> format(">>%2$*1$s<<", NULL, "hello")
>
> ???
>>>
>>> My first thought is that a NULL width should be treated the same as no
>>> width at
2013/2/9 Dean Rasheed :
>> 2013/1/31 Pavel Stehule :
>>> I am sending rewritten code
>
> Nice. I think this will be very useful, and it looks like it now
> supports everything that printf() does for %s format specifiers, and
> it's good that %I and %L behave the same. Also the code is looking
> cle
> 2013/1/31 Pavel Stehule :
>> I am sending rewritten code
Nice. I think this will be very useful, and it looks like it now
supports everything that printf() does for %s format specifiers, and
it's good that %I and %L behave the same. Also the code is looking
cleaner.
>> It indirect width "*" and
Hello
minor update - fix align NULL for %L
Regards
Pavel
2013/1/31 Pavel Stehule :
> Hello
>
> 2013/1/29 Dean Rasheed :
>> On 29 January 2013 08:19, Dean Rasheed wrote:
>>> * The width field is optional, even if the '-' flag is specified. So
>>> '%-s' is perfectly legal and should be interpret
Hello
2013/1/29 Dean Rasheed :
> On 29 January 2013 08:19, Dean Rasheed wrote:
>> * The width field is optional, even if the '-' flag is specified. So
>> '%-s' is perfectly legal and should be interpreted as '%s'. The
>> current implementation treats it as a width of 0, which is wrong.
>>
>
> Oh,
2013/1/29 Dean Rasheed :
> On 28 January 2013 20:32, Dean Rasheed wrote:
>> In general a format specifier looks like:
>>
>> %[parameter][flags][width][.precision][length]type
>>
>
> This highlights another problem with the current implementation ---
> the '-' flag and the width field need to be pa
2013/1/28 Tom Lane :
> Dean Rasheed writes:
>> On 28 January 2013 20:40, Pavel Stehule wrote:
>>> 2013/1/28 Dean Rasheed :
flags - not currently implemented. Pavel's second patch adds support
for the '-' flag for left justified string output. However, I think
this should support al
2013/1/28 Tom Lane :
> Pavel Stehule writes:
>> 2013/1/28 Dean Rasheed :
>>> Starting with the first patch - it issues a new WARNING if the format
>>> string contains a mixture of format specifiers with and without
>>> parameter indexes (e.g., 'Hello %s, %1$s').
>>>
>>> Having thought about it a b
On 29 January 2013 08:19, Dean Rasheed wrote:
> * The width field is optional, even if the '-' flag is specified. So
> '%-s' is perfectly legal and should be interpreted as '%s'. The
> current implementation treats it as a width of 0, which is wrong.
>
Oh, but of course a width of 0 is the same a
On 28 January 2013 20:32, Dean Rasheed wrote:
> In general a format specifier looks like:
>
> %[parameter][flags][width][.precision][length]type
>
This highlights another problem with the current implementation ---
the '-' flag and the width field need to be parsed separately. So
'%-3s' should be
Dean Rasheed writes:
> On 28 January 2013 20:40, Pavel Stehule wrote:
>> 2013/1/28 Dean Rasheed :
>>> flags - not currently implemented. Pavel's second patch adds support
>>> for the '-' flag for left justified string output. However, I think
>>> this should support all datatypes (i.e., %I and %L
On 28 January 2013 20:40, Pavel Stehule wrote:
> 2013/1/28 Dean Rasheed :
>> On 28 January 2013 17:32, Stephen Frost wrote:
>>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
Both. If we had done this when we first implemented format(), it'd be
fine, but it's too late to change it now. There
2013/1/28 Dean Rasheed :
> On 28 January 2013 17:32, Stephen Frost wrote:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>>> Both. If we had done this when we first implemented format(), it'd be
>>> fine, but it's too late to change it now. There very likely are
>>> applications out there that depend
On 28 January 2013 17:32, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Both. If we had done this when we first implemented format(), it'd be
>> fine, but it's too late to change it now. There very likely are
>> applications out there that depend on the current behavior. As D
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Both. If we had done this when we first implemented format(), it'd be
> fine, but it's too late to change it now. There very likely are
> applications out there that depend on the current behavior. As Dean
> says, it's not incompatible with SUS, just a su
Pavel Stehule writes:
> 2013/1/28 Dean Rasheed :
>> Starting with the first patch - it issues a new WARNING if the format
>> string contains a mixture of format specifiers with and without
>> parameter indexes (e.g., 'Hello %s, %1$s').
>>
>> Having thought about it a bit, I really don't like this
Hello
2013/1/28 Dean Rasheed :
> On 26 January 2013 10:58, Pavel Stehule wrote:
>> updated patches due changes for better variadic "any" function.
>>
>> apply fix_mixing_positinal_ordered_placeholders_warnings_20130126.patch first
>>
>
> Hi,
>
> No one is listed as a reviewer for this patch so I
On 26 January 2013 10:58, Pavel Stehule wrote:
> updated patches due changes for better variadic "any" function.
>
> apply fix_mixing_positinal_ordered_placeholders_warnings_20130126.patch first
>
Hi,
No one is listed as a reviewer for this patch so I thought I would
take a look at it, since it
Hello
2012/12/31 Pavel Stehule :
> Hello
>
> 2012/12/31 Stephen Frost :
>> Pavel,
>>
>> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>>> A result from ours previous talk was a completely disabling mixing
>>> positional and ordered placeholders - like is requested by man and gcc
>>> raises warn
Hello
2012/12/31 Stephen Frost :
> Pavel,
>
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> A result from ours previous talk was a completely disabling mixing
>> positional and ordered placeholders - like is requested by man and gcc
>> raises warnings there.
>>
>> But mixing is not explicitl
2012/12/31 Stephen Frost :
> Pavel,
>
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> A result from ours previous talk was a completely disabling mixing
>> positional and ordered placeholders - like is requested by man and gcc
>> raises warnings there.
>>
>> But mixing is not explicitly disal
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> A result from ours previous talk was a completely disabling mixing
> positional and ordered placeholders - like is requested by man and gcc
> raises warnings there.
>
> But mixing is not explicitly disallowed in doc, and mixing was tested
Hello
2012/12/31 Stephen Frost :
> Pavel,
>
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> I found one issue - if I disallow mixing positional and ordered style
>> I break compatibility with previous implementation.
>
> Can you elaborate? In the previous example, an error was returned when
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> I found one issue - if I disallow mixing positional and ordered style
> I break compatibility with previous implementation.
Can you elaborate? In the previous example, an error was returned when
mixing (not a terribly good one, but still
2012/12/30 Pavel Stehule :
> Hello Stephen
>
> 2012/12/29 Stephen Frost :
>> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>>> ok, so what is proposed solution?
>>
>> My recommendation would be to match what glibc's printf does.
>>
>>> I see two possibilities - a) applying my current patch - alt
Hello Stephen
2012/12/29 Stephen Frost :
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> ok, so what is proposed solution?
>
> My recommendation would be to match what glibc's printf does.
>
>> I see two possibilities - a) applying my current patch - although it
>> is not fully correct, b) n
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> ok, so what is proposed solution?
My recommendation would be to match what glibc's printf does.
> I see two possibilities - a) applying my current patch - although it
> is not fully correct, b) new patch, that do necessary check and raise
> more
2012/12/29 Stephen Frost :
> Pavel,
>
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> 2012/12/29 Stephen Frost :
>> > This is correct, if we're matching glibc (and SUS, I believe), isn't it?
>> > You're not allowed to mix '%2$s' type parameters and '%s' in a single
>> > format.
>>
>> I am not
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> 2012/12/29 Stephen Frost :
> > This is correct, if we're matching glibc (and SUS, I believe), isn't it?
> > You're not allowed to mix '%2$s' type parameters and '%s' in a single
> > format.
>
> I am not sure, please recheck
According to t
Hello
2012/12/29 Stephen Frost :
> Pavel,
>
> * Pavel Stehule (pavel.steh...@gmail.com) wrote:
>> I found so we doesn't have functionality for simply text aligning - so
>> I propose support width for %s like printf's behave. glibc
>> implementation knows a rule for precision, that I don't would to
Pavel,
* Pavel Stehule (pavel.steh...@gmail.com) wrote:
> I found so we doesn't have functionality for simply text aligning - so
> I propose support width for %s like printf's behave. glibc
> implementation knows a rule for precision, that I don't would to
> implement, because it is oriented to by
48 matches
Mail list logo
