Re: Making psql error out on output failures

On 2020-01-20 2:42 a.m., Daniel Verite wrote:
> David Zhang wrote:
>
>> Yes, I agree with you. For case 2 "select repeat('111', 1000000) \g
>> /mnt/ramdisk/file", it can be easily fixed with more accurate error
>> message similar to pg_dump, one example could be something like below.
>> But for case 1 "psql -d postgres -At -c "select repeat('111', 1000000)"
>>> /mnt/ramdisk/file" , it may require a lot of refactoring work.
> I don't quite see why you make that distinction? The relevant bits of
> code are common, it's all the code in src/fe_utils/print.c called
> from PrintQuery().

The reason is that, within PrintQuery() function call, one case goes to
print_unaligned_text(), and the other case goes to print_aligned_text().
The error "No space left on device" can be logged by fprintf() which is
redefined as pg_fprintf() when print_aligned_text() is called, however
the original c fputs function is used directly when
print_unaligned_text() is called, and it is used everywhere.

Will that be a better solution if redefine fputs similar to fprintf and
log the exact error when first time discovered? The concern is that if
we can't provide a more accurate information to the end user when error
happens, sometimes the end user might got even confused.

>
> Best regards,
--
David

Software Engineer
Highgo Software Inc. (Canada)
www.highgo.ca