On Wed, Aug 21, 2013 at 12:32:20PM +0200, Vik Fearing wrote:
> On 08/14/2013 11:27 PM, Bruce Momjian wrote:
> > On Mon, Aug 12, 2013 at 11:31:38PM -0400, Bruce Momjian wrote:
> >> On Mon, Aug 12, 2013 at 05:19:30PM -0400, Bruce Momjian wrote:
> >>> Attached are docs that add the new syntax, and men
On 08/14/2013 11:27 PM, Bruce Momjian wrote:
> On Mon, Aug 12, 2013 at 11:31:38PM -0400, Bruce Momjian wrote:
>> On Mon, Aug 12, 2013 at 05:19:30PM -0400, Bruce Momjian wrote:
>>> Attached are docs that add the new syntax, and mention it is
>>> non-standard; you can see the output here:
>>>
>>>
On Mon, Aug 12, 2013 at 11:31:38PM -0400, Bruce Momjian wrote:
> On Mon, Aug 12, 2013 at 05:19:30PM -0400, Bruce Momjian wrote:
> > Attached are docs that add the new syntax, and mention it is
> > non-standard; you can see the output here:
> >
> > http://momjian.us/tmp/pgsql/functions-string.
On Mon, Aug 12, 2013 at 05:19:30PM -0400, Bruce Momjian wrote:
> Attached are docs that add the new syntax, and mention it is
> non-standard; you can see the output here:
>
> http://momjian.us/tmp/pgsql/functions-string.html#FUNCTIONS-STRING-SQL
>
> We do document three syntaxes for substr
On Mon, Aug 12, 2013 at 04:58:23PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > We did have someone confused by what we have now, as well as me, so I
> > think there is a reason to clean this up. It would be a
> > backward-compatible change, though.
>
> backward-INcompatible, I assume you
Bruce Momjian writes:
> We did have someone confused by what we have now, as well as me, so I
> think there is a reason to clean this up. It would be a
> backward-compatible change, though.
backward-INcompatible, I assume you meant.
> To document this, I think we would need to add only one line
On Mon, Aug 12, 2013 at 02:18:01PM -0400, Tom Lane wrote:
> No, wait, I take that back. I was thinking that the function call would
> dump out as trim(x, y) but actually none of the underlying functions
> are named just "trim"; they're btrim, ltrim, or rtrim. So actually the
> dump/reload scenari
I wrote:
> This will break even more stuff than the last patch, ie, every single
> stored rule or view that contains a TRIM function. You can *not*
> eliminate, or mess with, the expr_list production, because that's what
> dumping of these function calls relies on.
No, wait, I take that back. I
Bruce Momjian writes:
> Based on my research, I am now proposing a new, attached patch which
> eliminates comma in all places in TRIM,
This will break even more stuff than the last patch, ie, every single
stored rule or view that contains a TRIM function. You can *not*
eliminate, or mess with, t
On Fri, Aug 9, 2013 at 12:23:59PM -0400, Bruce Momjian wrote:
> Yes, I have thought about this some more and another problem is that
> rtrim/btrim/ltrim() use the source string first, so having trim() have
> the source string second when using a comma is very confusing, e.g.:
>
> -- with pa
10 matches
Mail list logo
