Conversation
|
All contributors have signed the CLA ✍️ ✅ |
| ), | ||
| }; | ||
| pgrx::info!( | ||
| pgrx::debug1!( |
There was a problem hiding this comment.
Everywhere else in postgres or common extensions, CREATE EXTENSION does not produce any logs in the common success case. This change brings vchord to par with this expectation.
It is annoying when I am directly running commands in psql and unnecessary output logs move more important commands and outputs out of my terminal view.
There was a problem hiding this comment.
Everywhere else in postgres or common extensions,
CREATE EXTENSIONdoes not produce any logs in the common success case.
Do you mean CREATE INDEX? VectorChord should not print logs in CREATE EXTENSION.
This change brings vchord to par with this expectation.
We consider this a feature, so it would be inappropriate to hide it directly.
It is annoying when I am directly running commands in
psqland unnecessary output logs move more important commands and outputs out of my terminal view.
You can change all pgrx::info in the code to pgrx::notice. Then, use SET client_min_messages = warning to hide these messages.
There was a problem hiding this comment.
I found that you're not hiding the logs of clustering. I think this change is reasonable, although I don't understand why you ignore the 10+ lines of clustering-related logs above and only focus on the 3 lines at the bottom.
There was a problem hiding this comment.
ah, those had not triggered in my test run. now I see what you mean. happy to turn those into debug1 as well if that works for you!
There was a problem hiding this comment.
happy to turn those into
debug1as well if that works for you!
Keep it as it is.
usamoi
left a comment
usamoi
left a comment
There was a problem hiding this comment.
Please
- sign off commits by
git rebase HEAD~3 --signoff - sign CLA according to #444 (comment)
|
I have read the CLA Document and I hereby sign the CLA |
Co-authored-by: Artjoms Iskovs <mildbyte@gmail.com> Signed-off-by: Narek Galstyan <narekg@berkeley.edu>
…w debug logs Signed-off-by: Narek Galstyan <narekg@berkeley.edu>
The sphere() SQL functions were defined as 'SELECT ROW($1, $2)' which returns a generic record type. WHPG (Greenplum/PostgreSQL 12.12) is stricter about type matching in SQL function bodies and requires the return value to match the declared composite type exactly. This caused runtime errors: ERROR: return type mismatch in function declared to return sphere_vector DETAIL: Final statement returns record instead of vector at column 1. Fix by adding explicit casts: 'SELECT ROW($1, $2)::sphere_vector' Signed-off-by: Narek Galstyan <narekg@berkeley.edu>
Ngalstyan4
force-pushed
the
narek/pg12-fixes
branch
from
fcbd9a3 to
19d5b3e
Compare
2 participants
No description provided.