2015-03-10 19:50 GMT+01:00 Tom Lane <t...@sss.pgh.pa.us>: > Pavel Stehule <pavel.steh...@gmail.com> writes: > > 2015-03-10 15:30 GMT+01:00 Robert Haas <robertmh...@gmail.com>: > >> I am sure in agreement with the idea that it would be good to factor > >> out the common typecache code (for setting up my_extra). Any chance > >> we get a preliminary patch that does that refactoring, and then rebase > >> the main patch on top of it? I agree that it's not really this > >> patch's job to solve that problem, but it would be nice. > > > The common part is following code: > > There is not all that much commonality; many functions don't bother to > populate all of the ArrayMetaState fields because they don't need all of > them. (The ones you quote don't, in fact.) You are either going to end > up with a subroutine that does extra syscache lookups to populate the > whole struct every time, or a confusing collection of ad-hoc subroutines. > I'm not convinced that there's a lot of mileage to be gained here. >
I have not good feeling about it too. If we would to enhance this are, we probably need a specific flinfo field and flags to specify more precious the context of cached informations. my_extra should be reserved for generic usage. But still there is relative big space for settings some less common fields like "proc". With extra field in flinfo we can have interface like bool set_flinfo_type_cache(fcinfo, type, flags); and usage fcinfo->flinfo->typecache->typlen, .. I agree with Robert, this can be nice, but it needs more time for design :( Regards Pavel > > regards, tom lane >
