Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR)
От | Alexander Lakhin |
---|---|
Тема | Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR) |
Дата | |
Msg-id | f2e9506f-c0f3-4483-9f7b-711f9165f5b0@gmail.com обсуждение исходный текст |
Ответ на | Re: Better error reporting from extension scripts (Was: Extend ALTER OPERATOR) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
28.10.2024 19:06, Tom Lane wrote: >> I've also dumped buf in read_whole_file() and found that in both >> PG_BINARY_R and "r" modes the 0d 0a ending is preserved. But it changed >> to 0a with the "rt" mode (see [1]), and it makes the test (and the whole >> `meson test`) pass for me. > Interesting. I believe we decided years ago that we didn't need to > use "rt" mode because that was the default on Windows, but was that > a misreading of the documentation? The link you provided doesn't > give any hint that there are more than two behaviors. > > However ... the link you provided also mentions that text mode > includes treating control-Z as EOF; which I'd forgotten, but it > does make it less safe than I thought to use text mode for > reading script files. I think that this other behavior can be explained by pgwin32_fopen()/ pgwin32_open() coding (O_TEXT assumed implicitly only #ifdef FRONTEND). Anyway, as you noticed, \x1A injected into test_ext....sql really leads to the file contents truncation on read (with "rt"), so I agree that using the text/translation mode here is not an improvement. > What I'm now thinking is that we should revert 924e03917 after > all (that is, go back to using PG_BINARY_R) and instead make > read_whole_file manually squash \r\n to \n if we're on Windows. > Ugly, but I have yet to find anything about that platform that > isn't. Yes, I think this should help. Best regards, Alexander
В списке pgsql-hackers по дате отправления: