(6) possible inclusion in postgresql? - among other contributions? what about contrib/advisor? - added to template1 on default installation? maybe not for a first release? or yes? it is easier to communicate about
I think we're going to want a gborg project for developing/coordinating tests anyway. Having the schema included in contrib/ might help adoption, but so would pgadmin/phpgadmin. Any client-builders reading this? What do you think?
Both phpPgAdmin (me) and the pgAdmin team have added or have thought about adding some 'schema analysis' features to our products. If pg_advisor is available, I certainly won't bother and I will just recommend to people that they install it.
I think it probably should live in userland...
Yeah, this should live in userland.
Maybe this could be implemented as set of some descriptions, which is interpreted by a standalone tool, or interpreted by the gui tools available. This way, we could include a set of them into the admin tool distributions, ensuring a basic set is noticed by the admins (subject to update from contrib).
Currently, a check for old style fk triggers is hard-coded into pgadmin3 (to detect missing adddepend), because fk triggers are considered internal and thus suppressed.
There are plans (and basic work) for a FK index tool, which wouldn't be obsolete if a pg_advisor would detect it because it's intended to have a checkbox "fix this" in the list of detected fks.
Regards, Andreas
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
