| From: | Josh Berkus <josh(at)agliodbs(dot)com> |
|---|---|
| To: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Views, views, views! (long) |
| Date: | 2005-05-05 17:17:44 |
| Message-ID: | 200505051017.45071.josh@agliodbs.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andreas,
> As Dave already pointed out, serious admin tools will avoid views. We
> have to deal with version specific issues anyway.
Actually, I don't think that's what Dave said. He simply said that modifying
pgAdmin to keep up with pg_catalog changes hasn't actually been a problem.
And, as an increasing number of 3rd-party tools support PostgreSQL (like
Embarcadero) they need a simple comprehensible API for system objects -- more
objects than are included in the information_schema. I'm currently working
on the integration of a major DSS tool with PostgreSQL, and we're already
using the alpha version of the system views because we need them. A 3rd
party proprietary vendor is not going to learn about OIDs, and they're not
going to use pgAdmin.
When we discussed this on this list 2 months ago, I was under the impression
that extending the information_schema was verboten becuase it would break the
SQL spec. If that's not the case, I personally would love to not duplicate
objects. But let's establish that.
--
Josh Berkus
Aglio Database Solutions
San Francisco
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2005-05-05 17:19:08 | Re: [pgsql-advocacy] Increased company involvement |
| Previous Message | David F. Skoll | 2005-05-05 17:14:26 | A real puzzler: ANY way to recover? |