Re: pg_input_error_info doc 2 exampled crammed together
On Sun, Apr 28, 2024 at 10:07:49PM -0700, David G. Johnston wrote: > Agreed. The column names are self-explanatory if you’ve seen errors > before. The values are immaterial. Plus we don’t generally use > psql-specific features in our examples. Okay, I've just cleaned up that a bit with f6ab942f5de0. -- Michael signature.asc Description: PGP signature
Re: pg_input_error_info doc 2 exampled crammed together
On Sunday, April 28, 2024, Michael Paquier wrote: > On Sun, Apr 28, 2024 at 06:45:30PM -0700, David G. Johnston wrote: > > My preference would be to limit this section to a single example. The > > numeric one, as it provides values for more output columns. I would > change > > the output format to expanded from default, in order to show all columns > > and not overrun the length of a single line. > > Agreed that having two examples does not bring much, so this could be > brought to a single one. The first one is enough to show the point of > the function, IMO. It is shorter in width and it shows all the output > columns. > > Agreed. The column names are self-explanatory if you’ve seen errors before. The values are immaterial. Plus we don’t generally use psql-specific features in our examples. David J.
Re: pg_input_error_info doc 2 exampled crammed together
On Sun, Apr 28, 2024 at 06:45:30PM -0700, David G. Johnston wrote: > My preference would be to limit this section to a single example. The > numeric one, as it provides values for more output columns. I would change > the output format to expanded from default, in order to show all columns > and not overrun the length of a single line. Agreed that having two examples does not bring much, so this could be brought to a single one. The first one is enough to show the point of the function, IMO. It is shorter in width and it shows all the output columns. -- Michael signature.asc Description: PGP signature
Re: pg_input_error_info doc 2 exampled crammed together
On Sunday, April 28, 2024, jian he wrote: > > > after checking the definition of [1], [2], > maybe here we should use > Possibly, though I’d be curious to see how consistent we are on this point elsewhere before making a point of it. > > and also add `(1 row)` information. Doesn’t seem like added value. > > or we can simply add a empty new line between > ` value "420" is out of range for type integer || | > 22003` > and > `` My preference would be to limit this section to a single example. The numeric one, as it provides values for more output columns. I would change the output format to expanded from default, in order to show all columns and not overrun the length of a single line. David J.
pg_input_error_info doc 2 exampled crammed together
hi.
select * from pg_input_error_info('420', 'integer')
select message, detail from pg_input_error_info('1234.567', 'numeric(7,4)')
I found above two examples at [0] crammed together.
select * from pg_input_error_info('420',
'integer')
message| detail | hint
| sql_error_code
--++--+
value "420" is out of range for type integer || | 22003
select message, detail from
pg_input_error_info('1234.567', 'numeric(7,4)')
message | detail
+--&zwsp;-
numeric field overflow | A field with precision 7, scale 4 must round
to an absolute value less than 10^3.
after checking the definition of [1], [2],
maybe here we should use and also add `(1 row)` information.
or we can simply add a empty new line between
` value "420" is out of range for type integer || | 22003`
and
``
[0]
https://www.postgresql.org/docs/current/functions-info.html#FUNCTIONS-INFO-VALIDITY
[1] https://tdg.docbook.org/tdg/4.5/programlisting
[2] https://tdg.docbook.org/tdg/4.5/screen
--
I recommend David Deutsch's <>
Jian
