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