On Mon, Feb 10, 2025 at 02:02:10PM -0600, Sami Imseih wrote: > I am OK with moving away from "jumble" in-lieu of something else, but > my thoughts are we should actually call this process "fingerprint" > ( a term we already use in the queryjumblefuncs.c comment ). > A fingerprint consists of all the interesting parts of a node tree that are > appended and the final product is a hash of this fingerprint ( i.e. queryId ) > For node attributes we can specify "fingerprint_ignore" > or "no_fingerprint". What do you think?
I think that I have a long history of showing a bad naming sense, that I've done some follow-up API renames even on stable branches because folks didn't like some names, and that I have a reputation for that on these lists. :D Wikipedia seems to agree with you that "fingerprint" would fit for this purpose, though: https://en.wikipedia.org/wiki/Fingerprint_(computing) Has anybody any comments about that? That would be a large renaming, but in the long term is makes sense if we want to apply that to more than just parse nodes and query strings. If you do that, it impacts the file names and the properties, that are hidden in the backend for most of it, except the entry API and JumbleState. This last part impacts some extensions and I have been maintaining one a bit (pg_hint_plan). >> The concept of location does not apply to plans, based on the >> current proposal, so perhaps we should talk about "query normalization >> location"? > > Are you referring to JUMBLE_LOCATION? and whether to keep it in > queryjumblefuncs.c ( or jumblefuncs.c as is being proposed )? Yes, I am referring to the existing jumble location. I don't quite see how it fits with the plan part because we don't really have locations to track. Point worth noting, Alvaro has mentioned that he was planning to look at the pgss patch with IN clauses: https://www.postgresql.org/message-id/202502111214.fcfodex6t3sy@alvherre.pgsql Adding him in CC here for awareness, but I can see that both of you are involved on the other thread, as well. Also adding Julien in CC, as he has some out-of-core extension code that depends on the jumbling structures if I recall correctly. -- Michael
signature.asc
Description: PGP signature
