pgsql: Remove unused code related to unknown type
Remove unused code related to unknown type These are leftovers obsoleted by cfd9be939e9c516243c5b6a49ad1e1a9a38f1052. Reviewed-by: Tom Lane Discussion: https://www.postgresql.org/message-id/flat/e7887965-9e70-fd01-c2d1-5bc02f9169aa%40enterprisedb.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1b6f632a35f8715f8c64e7930adebc7f1d292074 Modified Files -- src/backend/utils/adt/varlena.c | 7 --- 1 file changed, 7 deletions(-)
pgsql: First-draft release notes for 15.2.
First-draft release notes for 15.2. As usual, the release notes for other branches will be made by cutting these down, but put them up for community review first. Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f282b026787da69d88a35404cf62f1cc21cfbb7c Modified Files -- doc/src/sgml/release-15.sgml | 1293 ++ 1 file changed, 1293 insertions(+)
pgsql: Make int64_div_fast_to_numeric() more robust.
Make int64_div_fast_to_numeric() more robust. The prior coding of int64_div_fast_to_numeric() had a number of bugs that would cause it to fail under different circumstances, such as with log10val2 <= 0, or log10val2 a multiple of 4, or in the "slow" numeric path with log10val2 >= 10. None of those could be triggered by any of our current code, which only uses log10val2 = 3 or 6. However, they made it a hazard for any future code that might use it. Also, since this is exported by numeric.c, users writing their own C code might choose to use it. Therefore fix, and back-patch to v14, where it was introduced. Dean Rasheed, reviewed by Tom Lane. Discussion: https://postgr.es/m/CAEZATCW8gXgW0tgPxPgHDPhVX71%2BSWFRkhnXy%2BTfGDsKLepu2g%40mail.gmail.com Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/86bfbeab4f439ad527318d9edeb3c71ea46c1ab3 Modified Files -- src/backend/utils/adt/numeric.c | 80 +++-- 1 file changed, 54 insertions(+), 26 deletions(-)
pgsql: Make int64_div_fast_to_numeric() more robust.
Make int64_div_fast_to_numeric() more robust. The prior coding of int64_div_fast_to_numeric() had a number of bugs that would cause it to fail under different circumstances, such as with log10val2 <= 0, or log10val2 a multiple of 4, or in the "slow" numeric path with log10val2 >= 10. None of those could be triggered by any of our current code, which only uses log10val2 = 3 or 6. However, they made it a hazard for any future code that might use it. Also, since this is exported by numeric.c, users writing their own C code might choose to use it. Therefore fix, and back-patch to v14, where it was introduced. Dean Rasheed, reviewed by Tom Lane. Discussion: https://postgr.es/m/CAEZATCW8gXgW0tgPxPgHDPhVX71%2BSWFRkhnXy%2BTfGDsKLepu2g%40mail.gmail.com Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4f74741a5cea38228fdb0fb2967fa2137ea02cbf Modified Files -- src/backend/utils/adt/numeric.c | 80 +++-- 1 file changed, 54 insertions(+), 26 deletions(-)
pgsql: Make int64_div_fast_to_numeric() more robust.
Make int64_div_fast_to_numeric() more robust. The prior coding of int64_div_fast_to_numeric() had a number of bugs that would cause it to fail under different circumstances, such as with log10val2 <= 0, or log10val2 a multiple of 4, or in the "slow" numeric path with log10val2 >= 10. None of those could be triggered by any of our current code, which only uses log10val2 = 3 or 6. However, they made it a hazard for any future code that might use it. Also, since this is exported by numeric.c, users writing their own C code might choose to use it. Therefore fix, and back-patch to v14, where it was introduced. Dean Rasheed, reviewed by Tom Lane. Discussion: https://postgr.es/m/CAEZATCW8gXgW0tgPxPgHDPhVX71%2BSWFRkhnXy%2BTfGDsKLepu2g%40mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b2d47928908d7a99b8e39198d0e8e9e0cb2b024b Modified Files -- src/backend/utils/adt/numeric.c | 73 ++--- 1 file changed, 46 insertions(+), 27 deletions(-)
pgsql: doc: Fix XML formatting that psql cannot handle
doc: Fix XML formatting that psql cannot handle Breaking over two lines is not handled by psql's create_help.pl. (It creates faulty \help output.) Undo the formatting change introduced by 9bdad1b5153e5d6b77a8f9c6e32286d6bafcd76d to fix this for now. Branch -- REL_15_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e7c2e02a66a2bbdfd937eace2e5838fd44ad1306 Modified Files -- doc/src/sgml/ref/fetch.sgml | 3 +-- doc/src/sgml/ref/move.sgml | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-)
pgsql: doc: Fix XML formatting that psql cannot handle
doc: Fix XML formatting that psql cannot handle Breaking over two lines is not handled by psql's create_help.pl. (It creates faulty \help output.) Undo the formatting change introduced by 9bdad1b5153e5d6b77a8f9c6e32286d6bafcd76d to fix this for now. Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a28bf818eaaa4bc71f492071b5a8e6bb0919e4ed Modified Files -- doc/src/sgml/ref/fetch.sgml | 3 +-- doc/src/sgml/ref/move.sgml | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-)
pgsql: doc: Fix XML formatting that psql cannot handle
doc: Fix XML formatting that psql cannot handle Breaking over two lines is not handled by psql's create_help.pl. (It creates faulty \help output.) Undo the formatting change introduced by 9bdad1b5153e5d6b77a8f9c6e32286d6bafcd76d to fix this for now. Branch -- REL_14_STABLE Details --- https://git.postgresql.org/pg/commitdiff/89d28f928c402e9f1890ece4d787825a6c51c2ca Modified Files -- doc/src/sgml/ref/fetch.sgml | 3 +-- doc/src/sgml/ref/move.sgml | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-)
pgsql: doc: Fix XML formatting that psql cannot handle
doc: Fix XML formatting that psql cannot handle Breaking over two lines is not handled by psql's create_help.pl. (It creates faulty \help output.) Undo the formatting change introduced by 9bdad1b5153e5d6b77a8f9c6e32286d6bafcd76d to fix this for now. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2010d8b75a6eb0f2ce90ae24cba99775c3d343e8 Modified Files -- doc/src/sgml/ref/fetch.sgml | 3 +-- doc/src/sgml/ref/move.sgml | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-)
pgsql: doc: Fix XML formatting that psql cannot handle
doc: Fix XML formatting that psql cannot handle Breaking over two lines is not handled by psql's create_help.pl. (It creates faulty \help output.) Undo the formatting change introduced by 9bdad1b5153e5d6b77a8f9c6e32286d6bafcd76d to fix this for now. Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/104c1c8daf343cfa7717e8536c9c6a44ecb75d92 Modified Files -- doc/src/sgml/ref/fetch.sgml | 3 +-- doc/src/sgml/ref/move.sgml | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-)
pgsql: doc: Fix XML formatting that psql cannot handle
doc: Fix XML formatting that psql cannot handle Breaking over two lines is not handled by psql's create_help.pl. (It creates faulty \help output.) Undo the formatting change introduced by 9bdad1b5153e5d6b77a8f9c6e32286d6bafcd76d to fix this for now. Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/c7b31ecc27f4056a40e17432dc17c1aeffe5d117 Modified Files -- doc/src/sgml/ref/fetch.sgml | 3 +-- doc/src/sgml/ref/move.sgml | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-)
Re: pgsql: Ensure that numeric.c compiles with other NBASE values.
On Fri, 3 Feb 2023 at 01:18, Tom Lane wrote: > > Dean Rasheed writes: > > > 1). It doesn't work if log10val2 < 0, because then m < 0, and it > > doesn't multiply by the remainder. And it then throws an overflow > > error, because result.dscale comes out wrong when m < 0. > > I'm not quite sure that it's worth expending code space on the > log10val2 < 0 case (compared to just "Assert(log10val2 >= 0"). > On the other hand, it's not much extra code, and committing it now > might save somebody reinventing that logic in future. > Yeah, I thought about that, but it's hardly any code to support that case. Also, this function is out there now (I found an example on Stack Overflow of someone using it), so we have no control over how people will use it in their own C code, and so I think it's worth making it robust across the range of possible inputs. Regards, Dean
