Teodor Macicas <teodor.macicas@epfl.ch> writes:
> Modifying the pg_statistics is not a good idea for most
> practical purposes.
That's what I've been telling you.
> We want to extend the system by doing the physical design
> outside the production database, and hence need to replicate the
> pg_statistics of the production database in another standing database.
Well, leaving aside the question of whether that's actually anywhere
near useful enough to justify the work, I'd *still* not support putting
the information into the second database's pg_statistic. pg_statistic
should contain the truth for that database's own tables. Seems like
what you need here is a second table along the lines of
pg_hypothetical_statistic, and then your planner hacks can include the
knowledge to look there instead of pg_statistic when doing hypothetical
planning.
Not that that's going to solve your immediate problem: there just isn't
any way at the SQL level to insert data into pg_statistic's anyarray
columns. You're going to need some specialized C function that inserts
the data, hopefully only after validating that the actual array type
matches the column that the stats are alleged to be for.
regards, tom lane