BUG #8335: trim() un-document behaviour
The following bug has been logged on the website:
Bug reference: 8335
Logged by: Jov
Email address: amutu@amutu.com
PostgreSQL version: 9.2.4
Operating system: suse 10 linux 64
Description:
in the postgresql doc 9.4,I find the trim() function like this:
trim([leading | trailing | both] [characters] from string)
so the trim should be pass only one argument with some optional prefix。but I
find the following calls with two argument is successfull but the results is
unexpected and wired：
##first call
postgres=# select trim(trailing ‘/’, ‘fasd/’);
rtrim
——-
(1 row)
-----!!!note: it return titile is rtrim----
## second call
postgres=# select trim(‘/’, ‘fasd/’)
;
btrim
——-
(1 row)
-----!!!note: it return titile is btrim----
it seems trim is transform to r、b、l trim internal，but the above call should
return error or it may produce un-expect results
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Fri, Jul 26, 2013 at 02:23:10AM +0000, amutu@amutu.com wrote:
in the postgresql doc 9.4,I find the trim() function like this:
trim([leading | trailing | both] [characters] from string)
so the trim should be pass only one argument with some optional prefix --- but I
find the following calls with two argument is successfull but the results is
unexpected and wired:##first call
postgres=# select trim(trailing '/, 'fasd/');
rtrim
------(1 row)
-----!!!note: it return titile is rtrim----## second call
postgres=# select trim('/', 'fasd/')
;
btrim
-----(1 row)
-----!!!note: it return titile is btrim----it seems trim is transform to rtrim internal but the above call should
return error or it may produce un-expect results
(I have cleaned up this posting because single-quotes were converted to
Unicode forward-backward quotes):
What is happening is that TRIM() is converted by the parser to calls to
base functions, e.g.
\df *trim*
List of functions
Schema | Name | Result data type | Argument data types | Type
------------+-------+------------------+---------------------+--------
pg_catalog | btrim | bytea | bytea, bytea | normal
pg_catalog | btrim | text | text | normal
pg_catalog | btrim | text | text, text | normal
pg_catalog | ltrim | text | text | normal
pg_catalog | ltrim | text | text, text | normal
pg_catalog | rtrim | text | text | normal
pg_catalog | rtrim | text | text, text | normal
That is why the headings don't say 'trim', but 'btrim', or similar ---
not sure we can easily improve that, and you can change the label with
AS.
The larger problem is the use of ',' instead of FROM, and the backwards
interpretation of the arguments. The query:
SELECT trim('/' FROM 'fasd/')
is internally converted to:
SELECT btrim('fasd/', '/')
Note the arguments are reversed. The comma syntax does not reverse the
arguments:
SELECT trim('/', 'fasd/')
is internally converted to:
SELECT btrim('/', 'fasd/')
You can even use modifiers like TRAILING with comma syntax:
SELECT trim(TRAILING '/', 'fasd/');
and that uses 'rtrim', but of course the behavior is still reverse of
expected.
Basically the odd comma behavior is because without a FROM, the
arguments are passed directly to btrim/rtrim/ltrim, and these functions
take the origin string first, then the string of characters to remove.
You are right this is undocumented.
The attached patch swaps the arguments in the parser, and allows your
expected behavior:
SELECT trim('x', 'xfasdx');
btrim
-------
fasd
Another option would be to change the C API for the b/r/ltrim functions,
or disallow the use of the comma TRIM syntax in the parser.
I am a little worried people might be relying on the trim/comma syntax
somewhere.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachments:
trim.difftext/x-diff; charset=us-asciiDownload
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
new file mode 100644
index 22e82ba..8419559
*** a/src/backend/parser/gram.y
--- b/src/backend/parser/gram.y
*************** substr_for: FOR a_expr { $$ = $2;
*** 11993,11999 ****
trim_list: a_expr FROM expr_list { $$ = lappend($3, $1); }
| FROM expr_list { $$ = $2; }
! | expr_list { $$ = $1; }
;
in_expr: select_with_parens
--- 11993,12000 ----
trim_list: a_expr FROM expr_list { $$ = lappend($3, $1); }
| FROM expr_list { $$ = $2; }
! | a_expr ',' a_expr { $$ = list_make2($3, $1); }
! | a_expr { $$ = list_make1($1); }
;
in_expr: select_with_parens
Running postgres 9.1.4 using pgAdmin3 on a macbook air intel OS 10.6
I just had this bug, using comma:
SELECT trim(trailing texte_natif , 'DATEDENAISSANCE' ) FROM CROP
returned the whole field, including the string 'DATEDENAISSANCE', but except
the very first character, the column being called rtrim.
Tryed to chang it to
SELECT trim(trailing texte_natif from 'DATEDENAISSANCE' ) FROM CROP
returned nothing ( as a dummy in postgres I can't say if it was null fields
or empty string...)
CROP.texte_natif is a quite long texte field,in which the STRING
'DATEDENAISSANCE can be present 0 to 3 times, and never before 20th
character
bests
Romain
--
View this message in context: http://postgresql.1045698.n5.nabble.com/BUG-8335-trim-un-document-behaviour-tp5765221p5766930.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Bruce Momjian <bruce@momjian.us> writes:
The attached patch swaps the arguments in the parser, and allows your
expected behavior:
This patch is completely unsafe. It will break stored rules, which may
contain calls using the existing argument order (which will be dumped
without any of the SQL-spec syntactic sugar). To say nothing of existing
applications that may be relying on calling the underlying functions with
their existing argument order.
The inconsistency in argument order is unfortunate but we're long since
stuck with it, I'm afraid.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On Fri, Aug 9, 2013 at 11:06:15AM -0400, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
The attached patch swaps the arguments in the parser, and allows your
expected behavior:This patch is completely unsafe. It will break stored rules, which may
contain calls using the existing argument order (which will be dumped
without any of the SQL-spec syntactic sugar). To say nothing of existing
applications that may be relying on calling the underlying functions with
their existing argument order.The inconsistency in argument order is unfortunate but we're long since
stuck with it, I'm afraid.
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 patch
SELECT trim('x', 'xabcx');
btrim
-------
abc
-- btrim
SELECT btrim('xabcx', 'x');
btrim
-------
abc
I think we can either document what we have, or remove the ability to
use comma with trim(). If we go with documentation, it is going to look
confusing as the optional modifier is going to be on the source string,
e.g.:
SELECT trim(both 'xabcx', 'x');
btrim
-------
abc
We could modify the grammar to force the modifier on the second
argument, but that is more parser states for limited value.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Finally could make it using
regexp_replace (my_field_to_trim, '.+my_triming_string' , '') for the "leading" case
regexp_replace (my_field_to_trim, 'my_triming_string(.+)' , '') for the "trailing" case
And both of them in this order a for the "both" one.
I don't know why, but could not use '*?'
Since in no instance my_triming_string was at the extremlity of the sting, I did not need it, but I guess something like '(|.+)my_triming_string'could have worked
________________________________
De : Bruce Momjian [via PostgreSQL] <ml-node+s1045698n5766983h79@n5.nabble.com>
À : Romain Billon-Grand <romainbillongrand@yahoo.fr>
Envoyé le : Vendredi 9 août 2013 18h24
Objet : Re: BUG #8335: trim() un-document behaviour
On Fri, Aug 9, 2013 at 11:06:15AM -0400, Tom Lane wrote:
Bruce Momjian <[hidden email]> writes:
The attached patch swaps the arguments in the parser, and allows your
expected behavior:This patch is completely unsafe. It will break stored rules, which may
contain calls using the existing argument order (which will be dumped
without any of the SQL-spec syntactic sugar). To say nothing of existing
applications that may be relying on calling the underlying functions with
their existing argument order.The inconsistency in argument order is unfortunate but we're long since
stuck with it, I'm afraid.
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 patch
SELECT trim('x', 'xabcx');
btrim
-------
abc
-- btrim
SELECT btrim('xabcx', 'x');
btrim
-------
abc
I think we can either document what we have, or remove the ability to
use comma with trim(). If we go with documentation, it is going to look
confusing as the optional modifier is going to be on the source string,
e.g.:
SELECT trim(both 'xabcx', 'x');
btrim
-------
abc
We could modify the grammar to force the modifier on the second
argument, but that is more parser states for limited value.
--
Bruce Momjian <[hidden email]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-bugs mailing list ([hidden email])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
________________________________
If you reply to this email, your message will be added to the discussion below:http://postgresql.1045698.n5.nabble.com/BUG-8335-trim-un-document-behaviour-tp5765221p5766983.html
To unsubscribe from BUG #8335: trim() un-document behaviour, click here.
NAML
--
View this message in context: http://postgresql.1045698.n5.nabble.com/BUG-8335-trim-un-document-behaviour-tp5765221p5767148.html
Sent from the PostgreSQL - bugs mailing list archive at Nabble.com.
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 patch
SELECT trim('x', 'xabcx');
btrim
-------
abc-- btrim
SELECT btrim('xabcx', 'x');
btrim
-------
abcI think we can either document what we have, or remove the ability to
use comma with trim(). If we go with documentation, it is going to look
confusing as the optional modifier is going to be on the source string,
e.g.:SELECT trim(both 'xabcx', 'x');
btrim
-------
abcWe could modify the grammar to force the modifier on the second
argument, but that is more parser states for limited value.
[ moved to hackers ]
Based on my research, I am now proposing a new, attached patch which
eliminates comma in all places in TRIM, e.g. this is no longer valid
either:
SELECT trim(BOTH FROM 'abc', 'a');
btrim
-------
bc
(1 row)
I believe the flexible TRIM syntax was introduced when TRIM was added in
1997:
commit 570620c5698b0c76b26a3ec71692df29375cad16
Author: Thomas G. Lockhart <lockhart@fourpalms.org>
Date: Mon Sep 1 06:00:35 1997 +0000
Add SQL92 string handling features (SUBSTRING, TRIM, EXTRACT).
We would now only support the documented TRIM syntax.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachments:
trim.difftext/x-diff; charset=us-asciiDownload
diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
new file mode 100644
index 22e82ba..aa88cfb
*** a/src/backend/parser/gram.y
--- b/src/backend/parser/gram.y
*************** substr_from:
*** 11991,11999 ****
substr_for: FOR a_expr { $$ = $2; }
;
! trim_list: a_expr FROM expr_list { $$ = lappend($3, $1); }
! | FROM expr_list { $$ = $2; }
! | expr_list { $$ = $1; }
;
in_expr: select_with_parens
--- 11991,11999 ----
substr_for: FOR a_expr { $$ = $2; }
;
! trim_list: a_expr FROM a_expr { $$ = list_make2($3, $1); }
! | FROM a_expr { $$ = list_make1($2); }
! | a_expr { $$ = list_make1($1); }
;
in_expr: select_with_parens
Bruce Momjian <bruce@momjian.us> 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, the expr_list production, because that's what
dumping of these function calls relies on.
It's easily a dozen years too late to change this, Bruce. Please just
think about documenting the underlying functions, if you feel a need
to do anything here.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 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 scenario does not have anything to do with the trim_list
production --- the underlying functions just parse normally in any case.
The question remains why it's a good idea to mess with a syntax behavior
that's been like that for a dozen years or more. I don't see any upside
to doing that. As an example of a downside, right now if you try to
pass extra arguments to TRIM() you'll get
regression=# select trim(1,2,3);
ERROR: function pg_catalog.btrim(integer, integer, integer) does not exist
LINE 1: select trim(1,2,3);
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
You might wonder why the message mentions "btrim" not "trim", but at least
the complaint is reasonably on-topic. After this patch, you'd just get
a "syntax error" message, which doesn't seem helpful at all.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 scenario does not have anything to do with the trim_list
production --- the underlying functions just parse normally in any case.
Right, TRIM is really just a wrapper around btrim/rtrim/ltrim.
The question remains why it's a good idea to mess with a syntax behavior
that's been like that for a dozen years or more. I don't see any upside
to doing that. As an example of a downside, right now if you try to
pass extra arguments to TRIM() you'll getregression=# select trim(1,2,3);
ERROR: function pg_catalog.btrim(integer, integer, integer) does not exist
LINE 1: select trim(1,2,3);
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.You might wonder why the message mentions "btrim" not "trim", but at least
the complaint is reasonably on-topic. After this patch, you'd just get
a "syntax error" message, which doesn't seem helpful at all.
Well, btrim/rtrim/ltrim only take two arguments, so allowing three for
it to fail later really doesn't seem to help much, compared to a syntax
error.
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.
To document this, I think we would need to add only one line:
trim([leading | trailing | both] [characters] from string)
new trim([leading | trailing | both] [from] string [, characters])
Of course, that second line is non-standard --- do we have to mention
that?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Bruce Momjian <bruce@momjian.us> 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:
trim([leading | trailing | both] [characters] from string)
new trim([leading | trailing | both] [from] string [, characters])
Of course, that second line is non-standard --- do we have to mention
that?
The second line is wrong no? We don't allow the LEADING etc keywords
in the expr_list alternative. Anyway, I'm dubious that we really want
to document a nonstandard syntax --- that would just be encouraging
people to use it, to little benefit.
Now that I've thought about this some more, I think that there was some
previous discussion around this syntax production, and that the reason
we left it like this is that we wanted to leave the door open for
user-defined trim functions that might take extra arguments. That
discussion probably predated 7.3 (when we added schemas) because the
code's current habit of forcing a "pg_catalog" prefix would make it
a little bit painful to add such functions. Still, you could do it
with superuser privileges. Not sure how strong that argument is,
but I think that's where we left it years ago.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Aug 12, 2013 at 04:58:23PM -0400, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> 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.
Yes.
To document this, I think we would need to add only one line:
trim([leading | trailing | both] [characters] from string)
new trim([leading | trailing | both] [from] string [, characters])Of course, that second line is non-standard --- do we have to mention
that?The second line is wrong no? We don't allow the LEADING etc keywords
in the expr_list alternative. Anyway, I'm dubious that we really want
to document a nonstandard syntax --- that would just be encouraging
people to use it, to little benefit.
Well, we just call trim_list rule the TRIM keyword rule, so it sure does
work:
SELECT trim(LEADING FROM 'abc', 'a');
ltrim
-------
bc
So, you are saying we should just leave it undocumented? It is true we
have gotten near-zero complaints about it in the past.
Now that I've thought about this some more, I think that there was some
previous discussion around this syntax production, and that the reason
we left it like this is that we wanted to leave the door open for
user-defined trim functions that might take extra arguments. That
discussion probably predated 7.3 (when we added schemas) because the
code's current habit of forcing a "pg_catalog" prefix would make it
a little bit painful to add such functions. Still, you could do it
with superuser privileges. Not sure how strong that argument is,
but I think that's where we left it years ago.
Oh, that does make sense why we had this syntax so open.
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 substring() in the same table, one row
for each, so there is precedent for doing this.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachments:
trim.difftext/x-diff; charset=us-asciiDownload
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
new file mode 100644
index 6154621..4a4a360
*** a/doc/src/sgml/func.sgml
--- b/doc/src/sgml/func.sgml
***************
*** 1296,1301 ****
--- 1296,1320 ----
<row>
<entry>
<indexterm>
+ <primary>trim</primary>
+ </indexterm>
+ <literal><function>trim(<optional>leading | trailing
+ | both</optional> <optional>from</optional>
+ <parameter>string</parameter>
+ <optional><parameter>, characters</parameter></optional>
+ )</function></literal>
+ </entry>
+ <entry><type>text</type></entry>
+ <entry>
+ Non-standard version of <function>trim()</>
+ </entry>
+ <entry><literal>trim(both 'x' from 'xTomxx')</literal></entry>
+ <entry><literal>Tom</literal></entry>
+ </row>
+
+ <row>
+ <entry>
+ <indexterm>
<primary>upper</primary>
</indexterm>
<literal><function>upper(<parameter>string</parameter>)</function></literal>
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 substring() in the same table, one row
for each, so there is precedent for doing this.
Attached is an updated patch with a proper example. I could move the
extra syntax into the description of the existing trim entry instead.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachments:
trim.difftext/x-diff; charset=us-asciiDownload
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
new file mode 100644
index 6154621..b21c433
*** a/doc/src/sgml/func.sgml
--- b/doc/src/sgml/func.sgml
***************
*** 1296,1301 ****
--- 1296,1320 ----
<row>
<entry>
<indexterm>
+ <primary>trim</primary>
+ </indexterm>
+ <literal><function>trim(<optional>leading | trailing
+ | both</optional> <optional>from</optional>
+ <parameter>string</parameter>
+ <optional><parameter>, characters</parameter></optional>
+ )</function></literal>
+ </entry>
+ <entry><type>text</type></entry>
+ <entry>
+ Non-standard version of <function>trim()</>
+ </entry>
+ <entry><literal>trim(both from 'xTomxx', 'x')</literal></entry>
+ <entry><literal>Tom</literal></entry>
+ </row>
+
+ <row>
+ <entry>
+ <indexterm>
<primary>upper</primary>
</indexterm>
<literal><function>upper(<parameter>string</parameter>)</function></literal>
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.html#FUNCTIONS-STRING-SQL
We do document three syntaxes for substring() in the same table, one row
for each, so there is precedent for doing this.Attached is an updated patch with a proper example. I could move the
extra syntax into the description of the existing trim entry instead.
Patch applied to head. I did not apply this to 9.3 in case we change
our minds about documenting this.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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:http://momjian.us/tmp/pgsql/functions-string.html#FUNCTIONS-STRING-SQL
We do document three syntaxes for substring() in the same table, one row
for each, so there is precedent for doing this.Attached is an updated patch with a proper example. I could move the
extra syntax into the description of the existing trim entry instead.Patch applied to head. I did not apply this to 9.3 in case we change
our minds about documenting this.
This commit introduced the following:
doc$ make -s html
Processing HTML.index...
2409 entries loaded...
collateindex.pl: duplicated index entry found: TRIM
1 entries ignored...
Done.
--
Vik
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 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 substring() in the same table, one row
for each, so there is precedent for doing this.Attached is an updated patch with a proper example. I could move the
extra syntax into the description of the existing trim entry instead.Patch applied to head. I did not apply this to 9.3 in case we change
our minds about documenting this.This commit introduced the following:
doc$ make -s html
Processing HTML.index...
2409 entries loaded...
collateindex.pl: duplicated index entry found: TRIM
1 entries ignored...
Done.
Interesting. I didn't realize HTML shows errors that 'make check'
doesn't. Anyway, I have removed the second index reference, so the
error should be gone now. Thanks for the report.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers