Function name "text_out" should be "textout"
Close to the bottom of:
https://www.postgresql.org/docs/devel/plpgsql-implementation.html
(and all previous version)
... the manual says:
During the ensuing assignment to the local variable curtime, the PL/pgSQL
interpreter casts this string to the timestamp type by calling the text_out
and timestamp_in functions for the conversion.
Should most probably be "textout" instead of "text_out". See:
test=# SELECT proname FROM pg_proc
WHERE proname IN ('text_out', 'textout');
proname
---------
textout
(1 row)
"timestamp_in" seems correct, though. Those function names seem rather
inconsistent: roughly half of them have the underscore, the rest doesn't.
Might explain the confusion.
SELECT * FROM pg_proc
WHERE proname ~ 'out$'
AND prorettype = 'cstring'::regtype
ORDER BY proname ~ '_out$';
SELECT * FROM pg_proc
WHERE proname ~ 'in$'
AND proargtypes = ARRAY['cstring'::regtype]::oidvector
ORDER BY proname ~ '_in$';
Regards
Erwin
On Sat, Jul 04, 2020 at 09:59:22AM +0200, Erwin Brandstetter wrote:
Close to the bottom of:
https://www.postgresql.org/docs/devel/plpgsql-implementation.html
(and all previous version)
... the manual says:During the ensuing assignment to the local variable curtime, the PL/pgSQL
interpreter casts this string to the timestamp type by calling the text_out
and timestamp_in functions for the conversion.Should most probably be "textout" instead of "text_out". See:
The doc is wrong and you are right, good catch. In the case of the
function logfunc2, the plpgsql parser assigns the value from 'now' by
using textout, then timestamp_in. I'll go fix this one, tomorrow if
possible, but most likely the day after. This error has existed for
22 years, since da63386 to be exact.
--
Michael
On Sat, Jul 04, 2020 at 09:57:08PM +0900, Michael Paquier wrote:
The doc is wrong and you are right, good catch. In the case of the
function logfunc2, the plpgsql parser assigns the value from 'now' by
using textout, then timestamp_in. I'll go fix this one, tomorrow if
possible, but most likely the day after. This error has existed for
22 years, since da63386 to be exact.
And fixed down to 9.5. Thanks Erwin for the report.
--
Michael