On Wed, Jul 29, 2015 at 11:28 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > It's possible that the problem here is not so much reliance on > shared_preload_libraries as it is that there's no provision in > pg_upgrade for dealing with the need to set it. But one way or > the other, this is a usability fail.
Andres pretty much put his finger on the problem here when he mentioned labels on shared objects. You can imagine trying to design this API so that when someone makes reference to label provider xyzzy we look for a function with that name that has some magic return type and call it, similar to what we already do with FDWs and what you recently implemented for TABLESAMPLE. But if the label is on a shared object, in which database shall we call that function? Even for database objects, it won't do at all if the same label provider name is used to mean different things in different databases. Speaking as the guy who came up with much of the design for feature and committed KaiGai's patch implementing it, I have to admit that I didn't think of what problems this would create for pg_upgrade. It seemed to me at the time that this really wasn't that different from something like pg_stat_statements, which also won't work properly unless loaded via shared_preload_libraries. In retrospect, there is a difference, which is that if you don't load pg_stat_statements, your DDL and queries will still execute, but in this case, they won't. That's definitely raising the table stakes, but I'm not sure what to do about it. Preserving shared_preload_libraries across pg_upgrade is a tempting solution, but that isn't guaranteed to solve more problems than it creates. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
