On Mon, Oct 18, 2010 at 1:07 PM, Pavel Stehule wrote:
> 2010/10/18, Robert Haas :
>> On Mon, Oct 18, 2010 at 7:37 AM, Itagaki Takahiro
>> wrote:
>>> On Sat, Oct 16, 2010 at 7:29 AM, Robert Haas
>>> wrote:
No doubt. The problem is that we're going to end up with those bells
and whistle
2010/10/18, Robert Haas :
> On Mon, Oct 18, 2010 at 7:37 AM, Itagaki Takahiro
> wrote:
>> On Sat, Oct 16, 2010 at 7:29 AM, Robert Haas
>> wrote:
>>> No doubt. The problem is that we're going to end up with those bells
>>> and whistles in two places: in to_char or other type-specific
>>> formatti
On Mon, Oct 18, 2010 at 7:37 AM, Itagaki Takahiro
wrote:
> On Sat, Oct 16, 2010 at 7:29 AM, Robert Haas wrote:
>> No doubt. The problem is that we're going to end up with those bells
>> and whistles in two places: in to_char or other type-specific
>> formatting functions, and again in format.
>
2010/10/18 Itagaki Takahiro :
> On Sat, Oct 16, 2010 at 7:29 AM, Robert Haas wrote:
>> No doubt. The problem is that we're going to end up with those bells
>> and whistles in two places: in to_char or other type-specific
>> formatting functions, and again in format.
>
> If we decide to use C-like
On Sat, Oct 16, 2010 at 7:29 AM, Robert Haas wrote:
> No doubt. The problem is that we're going to end up with those bells
> and whistles in two places: in to_char or other type-specific
> formatting functions, and again in format.
If we decide to use C-like sprintf(), I think the only thing we
On Fri, Oct 15, 2010 at 5:42 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Oct 15, 2010 at 10:54 AM, Tom Lane wrote:
>>> I think we should go into this with the idea that it might only do 10%
>>> of what sprintf can do initially, but there will be pressure to cover a
>>> lot of the other
Robert Haas writes:
> On Fri, Oct 15, 2010 at 10:54 AM, Tom Lane wrote:
>> I think we should go into this with the idea that it might only do 10%
>> of what sprintf can do initially, but there will be pressure to cover a
>> lot of the other 90% eventually.
> Hmm. I have a feeling that's going t
On Fri, Oct 15, 2010 at 10:54 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Oct 15, 2010 at 12:55 AM, Itagaki Takahiro
>> wrote:
>>> I agree that full-spec sprintf is too complex, but precision and
>>> zero-full for numeric types are commonly used. I think someone
>>> will ask us "Why don
Robert Haas writes:
> On Fri, Oct 15, 2010 at 12:55 AM, Itagaki Takahiro
> wrote:
>> I agree that full-spec sprintf is too complex, but precision and
>> zero-full for numeric types are commonly used. I think someone
>> will ask us "Why don't have numeric formats though we have %s?".
> I think so
On Fri, Oct 15, 2010 at 12:55 AM, Itagaki Takahiro
wrote:
> On Fri, Oct 15, 2010 at 12:59 PM, Pavel Stehule
> wrote:
>> then maybe %ls or %is - like "literal string" or "ident string".
>
> Yeah, good idea!
-1 from me. What does this do except make it more long-winded?
>> I don't think so merg
On Fri, Oct 15, 2010 at 8:20 PM, Pavel Stehule wrote:
> And the reply is - we have function to_char. I don't see any reason
> why we have to have two independent formatting systems.
The formats for literal and identifier can be replaced to quote_nullable() and
quote_ident(), too. Features to writ
2010/10/15 Itagaki Takahiro :
> On Fri, Oct 15, 2010 at 12:59 PM, Pavel Stehule
> wrote:
>> then maybe %ls or %is - like "literal string" or "ident string".
>
> Yeah, good idea!
>
>> I don't think so merging sprintf and format can be good. Sprintf is
>> too complex - so long years users don't kno
On Fri, Oct 15, 2010 at 12:59 PM, Pavel Stehule wrote:
> then maybe %ls or %is - like "literal string" or "ident string".
Yeah, good idea!
> I don't think so merging sprintf and format can be good. Sprintf is
> too complex - so long years users don't know specification well and
> creating some l
2010/10/15 Itagaki Takahiro :
> On Thu, Oct 14, 2010 at 9:50 PM, Andrew Dunstan wrote:
>> They're both somewhat arcane. But I think the C syntax is likely to be more
>> familiar to a wider group of users (including, for example, perl hackers)
>> than the C# syntax, and is to be preferred on those
On Thu, Oct 14, 2010 at 9:50 PM, Andrew Dunstan wrote:
> They're both somewhat arcane. But I think the C syntax is likely to be more
> familiar to a wider group of users (including, for example, perl hackers)
> than the C# syntax, and is to be preferred on those grounds alone.
OK, probably C synt
On 10/14/2010 08:25 AM, Robert Haas wrote:
IMHO, I like {} syntax as like as C# because the format strings are extensible.
{ pos [ : format ] } -- ex {3:l}, {3} (, and {l} could be also supported)
Escapes: {{ => {, }} => }
My personal preference (and Pavel's, I guess) is to use the C-l
On Thu, Oct 14, 2010 at 2:25 AM, Itagaki Takahiro
wrote:
>> Let's make format support %s, %i, and %l, as well as
>> allowing things like %$3l (meaning, escape the third argument as a
>> literal and interpolate here), and call it good.
>
> Your idea is:
> % [ $ pos ] format -- ex. %$3l , %l
> Es
On Thu, Oct 14, 2010 at 10:23 AM, Robert Haas wrote:
> On Wed, Sep 29, 2010 at 3:59 AM, Pavel Stehule
> wrote:
>> [ updated patch, in response to a review from Itagaki Takahiro ]
>
> This patch appears to be waiting for a second round of review.
> Itagaki-san, are you planning to do that?
I can
On Wed, Sep 29, 2010 at 3:59 AM, Pavel Stehule wrote:
> [ updated patch, in response to a review from Itagaki Takahiro ]
This patch appears to be waiting for a second round of review.
Itagaki-san, are you planning to do that?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterpri
2010/10/14 Robert Haas :
> On Wed, Oct 13, 2010 at 10:03 PM, Itagaki Takahiro
> wrote:
>> On Thu, Oct 14, 2010 at 10:23 AM, Robert Haas wrote:
>>> On Wed, Sep 29, 2010 at 3:59 AM, Pavel Stehule
>>> wrote:
[ updated patch, in response to a review from Itagaki Takahiro ]
>>>
>>> This patch a
On Wed, Oct 13, 2010 at 10:03 PM, Itagaki Takahiro
wrote:
> On Thu, Oct 14, 2010 at 10:23 AM, Robert Haas wrote:
>> On Wed, Sep 29, 2010 at 3:59 AM, Pavel Stehule
>> wrote:
>>> [ updated patch, in response to a review from Itagaki Takahiro ]
>>
>> This patch appears to be waiting for a second r
> Let's make format support %s, %i, and %l, as well as
> allowing things like %$3l (meaning, escape the third argument as a
> literal and interpolate here), and call it good.
Your idea is:
% [ $ pos ] format -- ex. %$3l , %l
Escapes: %% => %
Just for information, $ and pos are reversed in C
Hello
2010/10/14 Itagaki Takahiro :
>> Let's make format support %s, %i, and %l, as well as
>> allowing things like %$3l (meaning, escape the third argument as a
>> literal and interpolate here), and call it good.
>
> Your idea is:
> % [ $ pos ] format -- ex. %$3l , %l
> Escapes: %% => %
>
> Ju
Excerpts from Itagaki Takahiro's message of mié oct 13 23:03:16 -0300 2010:
> On Thu, Oct 14, 2010 at 10:23 AM, Robert Haas wrote:
> > On Wed, Sep 29, 2010 at 3:59 AM, Pavel Stehule
> > wrote:
> >> [ updated patch, in response to a review from Itagaki Takahiro ]
> >
> > This patch appears to be
Hello
2010/9/29 Itagaki Takahiro :
> On Thu, Sep 9, 2010 at 8:57 PM, Pavel Stehule wrote:
>> I am sending a updated version.
>>
>> changes:
>> * tag %v removed from format function,
>> * proprietary tags %lq a iq removed from sprintf
>> * code cleaned
>>
>> patch divided to two parts - format fun
On Thu, Sep 9, 2010 at 8:57 PM, Pavel Stehule wrote:
> I am sending a updated version.
>
> changes:
> * tag %v removed from format function,
> * proprietary tags %lq a iq removed from sprintf
> * code cleaned
>
> patch divided to two parts - format function and stringfunc (contains
> sprintf funct
Hello
I am sending a updated version.
changes:
* tag %v removed from format function,
* proprietary tags %lq a iq removed from sprintf
* code cleaned
patch divided to two parts - format function and stringfunc (contains
sprintf function and substitute function)
Regards
Pavel Stehule
2010/9
2010/9/6 Itagaki Takahiro :
> On Mon, Sep 6, 2010 at 11:24 PM, Tom Lane wrote:
>> So? You'd need to quote the values anyway, in general. If you want
>> something that will be valid SQL you'd better include the functionality
>> of quote_literal() in it.
>>
>> I'm not sure that it's a good idea to
On Mon, Sep 6, 2010 at 11:24 PM, Tom Lane wrote:
> So? You'd need to quote the values anyway, in general. If you want
> something that will be valid SQL you'd better include the functionality
> of quote_literal() in it.
>
> I'm not sure that it's a good idea to have any type-specific special
> c
Pavel Stehule writes:
> Why I think so this is useful - sometimes people asked some GUC for
> formatting date, boolean and other. If these functions try to use a
> cast to text first, then there is some space for customization via
> custom cast functions.
This is basically nonsense. If you don't
Itagaki Takahiro writes:
> On Mon, Sep 6, 2010 at 10:47 PM, Tom Lane wrote:
>> No, you need to use the I/O functions. Â Not every type is guaranteed to
>> have a cast to text.
> One issue is that Pavel want to generate valid SQL statement using
> %v format. Boolean values are printed as t or f,
2010/9/6 Itagaki Takahiro :
> On Mon, Sep 6, 2010 at 10:47 PM, Tom Lane wrote:
>> No, you need to use the I/O functions. Not every type is guaranteed to
>> have a cast to text.
>
> One issue is that Pavel want to generate valid SQL statement using
> %v format. Boolean values are printed as t or f
2010/9/6 Tom Lane :
> Pavel Stehule writes:
>> 2010/9/6 Itagaki Takahiro :
>>> Which should we use for such purposes? Consistent behavior is
>>> obviously preferred. Boolean type might be the only type that
>>> is converted to different representation in typoutput or cast-to-test,
>>> but we shoul
On Mon, Sep 6, 2010 at 10:47 PM, Tom Lane wrote:
> No, you need to use the I/O functions. Not every type is guaranteed to
> have a cast to text.
One issue is that Pavel want to generate valid SQL statement using
%v format. Boolean values are printed as t or f, so the unquoted
values are not vali
Pavel Stehule writes:
> 2010/9/6 Itagaki Takahiro :
>> Which should we use for such purposes? Consistent behavior is
>> obviously preferred. Boolean type might be the only type that
>> is converted to different representation in typoutput or cast-to-test,
>> but we should consider to have boolean-
2010/9/6 Itagaki Takahiro :
> On Wed, Sep 1, 2010 at 1:29 PM, Pavel Stehule wrote:
>>> * %v also doesn't quote boolean values, but t and f are not valid.
>>> You should use true and false (or 't' and 'f') for the cases.
>>
>> you have a true - it should be fixed
>
> I found quote_literal() prints
On Wed, Sep 1, 2010 at 1:29 PM, Pavel Stehule wrote:
>> * %v also doesn't quote boolean values, but t and f are not valid.
>> You should use true and false (or 't' and 'f') for the cases.
>
> you have a true - it should be fixed
I found quote_literal() prints boolean values as 'true' or 'false'.
2010/9/1 Itagaki Takahiro :
> On Wed, Sep 1, 2010 at 6:07 AM, Pavel Stehule wrote:
>> I don't found a nice mix for placeholders and positional placeholders
>
> How about %pos$format, used in C-printf()? It might be
> only in Linux's libc.
>
> printf("<%2$s> <%1$d>\n", 123, "abc");
> => <123>
> ht
2010/9/1 David Fetter :
> On Tue, Aug 31, 2010 at 11:07:40PM +0200, Pavel Stehule wrote:
>> Hello
>>
>> attached WIP patch.
>
> I don't see it attached. Is it just me?
sorry, it was at 1 ofter midnight
Regards
Pavel
>
> Cheers,
> David.
> --
> David Fetter http://fetter.org/
> Phone: +1 415 2
On Wed, Sep 1, 2010 at 6:07 AM, Pavel Stehule wrote:
> I don't found a nice mix for placeholders and positional placeholders
How about %pos$format, used in C-printf()? It might be
only in Linux's libc.
printf("<%2$s> <%1$d>\n", 123, "abc");
=> <123>
http://linux.die.net/man/3/printf
> %i ... s
On Tue, Aug 31, 2010 at 11:07:40PM +0200, Pavel Stehule wrote:
> Hello
>
> attached WIP patch.
I don't see it attached. Is it just me?
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.co
On Aug 31, 2010, at 5:07 PM, Pavel Stehule wrote:
> Hello
>
> attached WIP patch.
>
> I implement only basic format's tags related to SQL: string, value,
> literal, sql identifier. These tags are basic, but there are not any
> break to implement any other formats or enhance a syntax. The mix wi
Hello
attached WIP patch.
I implement only basic format's tags related to SQL: string, value,
literal, sql identifier. These tags are basic, but there are not any
break to implement any other formats or enhance a syntax. The mix with
to_char function is more complex then I expected - so I don't t
2010/8/30 Alvaro Herrera :
> Excerpts from Pavel Stehule's message of lun ago 30 07:51:55 -0400 2010:
>> 2010/8/30 Itagaki Takahiro :
>> > On Mon, Aug 30, 2010 at 7:58 PM, Pavel Stehule
>> > wrote:
>> >> propsals:
>> >> * "format" function - uses same formatting as PL/pgSQL RAISE statement
>> >>
Excerpts from Pavel Stehule's message of lun ago 30 07:51:55 -0400 2010:
> 2010/8/30 Itagaki Takahiro :
> > On Mon, Aug 30, 2010 at 7:58 PM, Pavel Stehule
> > wrote:
> >> propsals:
> >> * "format" function - uses same formatting as PL/pgSQL RAISE statement
> >> * "sprintf" function
> >>
> >> Now
2010/8/30 Itagaki Takahiro :
> On Mon, Aug 30, 2010 at 7:58 PM, Pavel Stehule
> wrote:
>> propsals:
>> * "format" function - uses same formatting as PL/pgSQL RAISE statement
>> * "sprintf" function
>>
>> Now I propose a compromise - "format" function with only three tags:
>> %s .. some string
>>
On Mon, Aug 30, 2010 at 7:58 PM, Pavel Stehule wrote:
> propsals:
> * "format" function - uses same formatting as PL/pgSQL RAISE statement
> * "sprintf" function
>
> Now I propose a compromise - "format" function with only three tags:
> %s .. some string
> %i .. SQL identifier
> %l .. string lit
Hello
I am returning back to string functions. For me, the most important
function isn't commited still. There was discussion about "format" or
"sprintf" fuction. So I'll do a small resume.
goal: to get function that helps with formatting a message texts and
helps with building a SQL commands (us
48 matches
Mail list logo
