postgres

History

Tom Lane fadff3fc94 Prevent mis-encoding of "trailing junk after numeric literal" errors. Since commit `2549f0661`, we reject an identifier immediately following a numeric literal (without separating whitespace), because that risks ambiguity with hex/octal/binary integers. However, that patch used token patterns like "{integer}{ident_start}", which is problematic because {ident_start} matches only a single byte. If the first character after the integer is a multibyte character, this ends up with flex reporting an error message that includes a partial multibyte character. That can cause assorted bad-encoding problems downstream, both in the report to the client and in the postmaster log file. To fix, use {identifier} not {ident_start} in the "junk" token patterns, so that they will match complete multibyte characters. This seems generally better user experience quite aside from the encoding problem: for "123abc" the error message will now say that the error appeared at or near "123abc" instead of "123a". While at it, add some commentary about why these patterns exist and how they work. Report and patch by Karina Litskevich; review by Pavel Borisov. Back-patch to v15 where the problem came in. Discussion: https://postgr.es/m/CACiT8iZ_diop=0zJ7zuY3BXegJpkKK1Av-PU7xh0EDYHsa5+=g@mail.gmail.com		1 year ago
..
compatlib	Revert ECPG's use of pnstrdup()	1 year ago
ecpglib	Fix inappropriate uses of atol()	1 year ago
include	Remove obsolete symbol from ecpg_config.h.in	2 years ago
pgtypeslib	thread-safety: gmtime_r(), localtime_r()	1 year ago
preproc	Prevent mis-encoding of "trailing junk after numeric literal" errors.	1 year ago
test	Add -Wmissing-variable-declarations to the standard compilation flags	1 year ago
Makefile	Remove distprep	2 years ago
README.dynSQL	…
meson.build	Update copyright for 2024	2 years ago

README.dynSQL

src/interfaces/ecpg/README.dynSQL

descriptor statements have the following shortcomings

- input descriptors (USING DESCRIPTOR <name>) are not supported

  Reason: to fully support dynamic SQL the frontend/backend communication
          should change to recognize input parameters.
          Since this is not likely to happen in the near future and you
          can cover the same functionality with the existing infrastructure
          (using s[n]printf), I'll leave the work to someone else.