More outdated documentation
Example 7-5 in the User's Guide is also outdated, because there is now a
function substr for bytea, so the mechanics the example tries to
illustrate are a tad more complicated. New example requested.
--
Peter Eisentraut peter_e@gmx.net
Peter Eisentraut wrote:
Example 7-5 in the User's Guide is also outdated, because there is now a
function substr for bytea, so the mechanics the example tries to
illustrate are a tad more complicated. New example requested.
Here's a new example, as requested.
Joe
Attachments:
typeconv.sgml.1.patchtext/html; name=typeconv.sgml.1.patchDownload
Index: doc/src/sgml/typeconv.sgml
===================================================================
RCS file: /opt/src/cvs/pgsql-server/doc/src/sgml/typeconv.sgml,v
retrieving revision 1.26
diff -c -r1.26 typeconv.sgml
*** doc/src/sgml/typeconv.sgml 19 Feb 2003 04:06:28 -0000 1.26
--- doc/src/sgml/typeconv.sgml 8 Mar 2003 20:09:56 -0000
***************
*** 625,645 ****
</example>
<example>
! <title>Substring Function Type Resolution</title>
<para>
! There are two <function>substr</function> functions declared in <classname>pg_proc</classname>. However,
! only one takes two arguments, of types <type>text</type> and <type>int4</type>.
</para>
<para>
! If called with a string constant of unspecified type, the type is matched up
directly with the only candidate function type:
<screen>
! tgl=> SELECT substr('1234', 3);
! substr
! --------
! 34
(1 row)
</screen>
</para>
--- 625,645 ----
</example>
<example>
! <title>Right-pad Function Type Resolution</title>
<para>
! There are two <function>rpad</function> functions declared in <classname>pg_proc</classname>. However,
! only one takes three arguments, of types <type>text</type>, <type>int4</type>, and <type>text</type>.
</para>
<para>
! If called with the first string constant of unspecified type, the type is matched up
directly with the only candidate function type:
<screen>
! regression=# SELECT rpad('1234', 7, 'x');
! rpad
! ---------
! 1234xxx
(1 row)
</screen>
</para>
***************
*** 648,665 ****
If the string is declared to be of type <type>varchar</type>, as might be the case
if it comes from a table, then the parser will try to coerce it to become <type>text</type>:
<screen>
! tgl=> SELECT substr(varchar '1234', 3);
! substr
! --------
! 34
(1 row)
</screen>
which is transformed by the parser to become
<screen>
! tgl=> SELECT substr(text(varchar '1234'), 3);
! substr
! --------
! 34
(1 row)
</screen>
</para>
--- 648,665 ----
If the string is declared to be of type <type>varchar</type>, as might be the case
if it comes from a table, then the parser will try to coerce it to become <type>text</type>:
<screen>
! regression=# SELECT rpad(varchar '1234', 7, 'x');
! rpad
! ---------
! 1234xxx
(1 row)
</screen>
which is transformed by the parser to become
<screen>
! regression=# SELECT rpad(text(varchar '1234'), 7, 'x');
! rpad
! ---------
! 1234xxx
(1 row)
</screen>
</para>
***************
*** 678,695 ****
And, if the function is called with an <type>int4</type>, the parser will
try to convert that to <type>text</type>:
<screen>
! tgl=> SELECT substr(1234, 3);
! substr
! --------
! 34
(1 row)
</screen>
which actually executes as
<screen>
! tgl=> SELECT substr(text(1234), 3);
! substr
! --------
! 34
(1 row)
</screen>
This succeeds because there is a conversion function text(int4) in the
--- 678,695 ----
And, if the function is called with an <type>int4</type>, the parser will
try to convert that to <type>text</type>:
<screen>
! regression=# SELECT rpad(1234, 7, 'x');
! rpad
! ---------
! 1234xxx
(1 row)
</screen>
which actually executes as
<screen>
! regression=# SELECT rpad(text(1234), 7, 'x');
! rpad
! ---------
! 1234xxx
(1 row)
</screen>
This succeeds because there is a conversion function text(int4) in the
Hmm, I already fixed all the outdated examples in my local copy. Sorry
that I forgot to mention it.
Joe Conway writes:
Peter Eisentraut wrote:
Example 7-5 in the User's Guide is also outdated, because there is now a
function substr for bytea, so the mechanics the example tries to
illustrate are a tad more complicated. New example requested.Here's a new example, as requested.
Joe
--
Peter Eisentraut peter_e@gmx.net