The queryId attached to Query and PlannedStmt should actually work pretty well for anything here. We can just assign an ID to them that we can use as a lookup key for any additional state attached to these objects.

I've also seen extensions "extend" structs like:

typedef struct {
  Query query;
  int x;
  int y;
} ContinuousQuery;

That might be simpler? In our code, we just assume that a Query * is actually a ContinuousQuery *.

That approach feels brittle to me within the context of the planner/analyzer, as it's at the mercy of the unverifiable assumption that the pointer is never repalloc'd anywhere within these deep and complex code paths (including by other extensions!). Using embedded structs works well for significantly simpler code paths though, such as with custom scan states.

This is really what the queryId attached to Query and PlannedStmt are designed for, so I feel like we should leverage the design when such facilities are cleanly available to us.

That makes sense to me! 9.6 also has some faster and lighter implementation of hash tables.

That makes sense to me! 9.6 also has some faster and lighter implementation of hash tables.

Good lord, finally!

I'll try and find that. I remember seeing in months ago.

Not sure if this was it: https://www.postgresql.org/message-id/[email protected]