Tzahi Fadida <tzahi_ml@myrealbox.com> writes:
> I am writing an algorithm in a dynamic c library and using heap_fetch.
> I want to pin strategic buffers for long times like an Outer
> joins might do for the inner table.
> Do i to also need to lock the table somehow?
You didn't say enough about the context. It is *always* necessary to
have some type of lock on a table you are accessing --- otherwise some
other backend could drop the table out from under you. But in many
scenarios this is taken care of at a pretty high level, like executor
startup. What is your "algorithm" and when is it applied? How does it
get the table to be accessed?
> I am only reading the tuple but maybe other transactions will
> want to write to it and when I am looping over
> the table like in an outer join does I can get different
> values and I want to avoid that.
> or that can't happen when pinning?
Pinning has nothing to do with that --- maintaining a consistent
snapshot setting does.
> Another question, when a column attribute is toasted,
> do I need to do another heap_fetch aside from the main
> table to fetch the data from the adjoined toasted table?
> How do I also pin the toasted table buffer pages?
No, you do a DETOAST_DATUM call.
> And last general question,
> what is the best way to compare two datums?
> datumIsEqual doc says its not enough because of
> different representations, and if its toasted it won't
> work (maybe if its detoasted first).
You really should locate the datatype's equality function and call that.
datumIsEqual is a kluge that is only safe to use in the very limited
context of equalfuncs.c (basically, it's OK to say that two Const nodes
are different if they are bitwise different, even if the represented
values are logically equal).
Look at array_eq() for an example of current best practice for this.
regards, tom lane