> There is a hook "post_parse_analyze_hook" but I think it comes too
> late as it comes after the analyze step which is when Postgres looks
> up the schema information for every relation mentioned in the query.
> What you would need is a post_parse_hook which would work on the raw
> parse tree before the analyze step. That doesn't seem terribly
> controversial to add though there may be some technical details. The
> API would of course be completely unstable from major release to major
> release -- the parse tree gets knocked around quite a bit.
Good to know that parse tree is not stable. My original proposal was exactly the one you describe. I called it
post_raw_parse_hookand wanted to call it from exec_simple_query(), right after pg_parse_query().
May be not the best place or way to achieve this?
It was a few liner patch, I wonder if it ever has a chance to get into Postgres.
> And I have to wonder if you aren't going the long way around to do
> something that can be done more simply some other way. If you have
> 150k objects I wonder if your objects aren't all very similar and
> could be handled by a single Postgres schema object. Either a single
> FDW object or a simple function.
I need to do a bit more research on that side. I was hoping to spend less time on understanding that legacy system...
> As a side note, you should evaluate carefully what lazily creating
> objects will buy you. Perhaps just creating 150k objects would be
> cheaper than maintaining this code. In particular since the user
> *might* access all 150k you still have to worry about the worst case
> anyway and it might be cheaper to just engineer for it in the first
> place.
I have a similar problem with the legacy system. The set of 150k objects may change in between releases. My gut feeling
isthat it is easier to understand and keep track of an open source project like Postgres.
Best regards and thanks for all insights and ideas, David
