On Thu, May 12, 2005 at 16:59:07 -0700,
David Fetter [EMAIL PROTECTED] wrote:
A PostgreSQL developer has shown in this very thread that it is
extremely easy to screw up a query against those catalogs. Maybe
you're better than he is, but that's not a reason to keep something
simpler out.
Tom Lane wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
Argument 3: backwards compatibility. Do you remember how
tablespaces
introduction broke pgAdmin?
This argument, at least, is bogus. See my original comments to Josh:
it is not credible that these views will be significantly more
Merlin Moncure [EMAIL PROTECTED] writes:
However, I think PostgreSQL has a fairly serious security problem in
that the system catalogs are open to the public. I don't seem to be
winning many supporters on this particular point though.
No, you're not, and it's not like we've never heard this
Tom Lane wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
However, I think PostgreSQL has a fairly serious security problem in
that the system catalogs are open to the public. I don't seem to be
winning many supporters on this particular point though.
No, you're not, and it's not like
Andrew Dunstan wrote:
Tom Lane wrote:
Merlin Moncure [EMAIL PROTECTED] writes:
However, I think PostgreSQL has a fairly serious security problem in
that the system catalogs are open to the public. I don't seem to be
winning many supporters on this particular point though.
No, you're not,
Merlin Moncure wrote:
I tried it from that angle and could only come up with two modes:
'pgadmin on' and 'pgadmin off' (per user). If you can do better, I'd be
thrilled. I also don't want to overblow my own argument...the database
can be secured quite effectively if you know what to do. It
Andrew, Merlin,
My approach was to remove all significant permissions (including on the
catalog) from public and regrant them to a pseudopublic group,
comprising designated users. The designated users would notice no
difference at all, while everyone else would be able to see only what
was
Josh Berkus josh@agliodbs.com writes:
Andrew, Merlin,
My approach was to remove all significant permissions (including on the
catalog) from public and regrant them to a pseudopublic group,
comprising designated users. The designated users would notice no
difference at all, while everyone else
Josh Berkus wrote:
Andrew, Merlin,
My approach was to remove all significant permissions (including on the
catalog) from public and regrant them to a pseudopublic group,
comprising designated users. The designated users would notice no
difference at all, while everyone else would be able to
Andrew,
Not really, no. It would just be one more thing that my hardening script
had to remove permissions from.
Hmmm ... even though the sysviews check users' permissions? That was one of
our ideas behind making it safer than the system catalogs.
I still have an open mind about the
Josh Berkus wrote:
Andrew,
Not really, no. It would just be one more thing that my hardening script
had to remove permissions from.
Hmmm ... even though the sysviews check users' permissions? That was one of
our ideas behind making it safer than the system catalogs.
It might be
On 2005-05-13, Andrew Dunstan [EMAIL PROTECTED] wrote:
Josh Berkus wrote:
plugDoesn't it seem like a really complete set of system views (based on
information_schema or otherwise) would potentially allow securing the
pg_catalog?/plug
Not really, no. It would just be one more thing that my
On Thu, May 12, 2005 at 04:03:39PM -0400, Andrew Dunstan wrote:
I still don't have any strong views, but I do want the target audience
specified - I have seen conflicting messages on that. Power users? Admin
Tool builders? Client library builders? These groups don't all have the
same needs.
Andrew - Supernews wrote:
Most significantly, there is a lot of comment on what people _think_
we could do (or not do), and no comment about what we actually _did_.
I strongly suggest to anyone thinking of commenting on them that you
actually install them and look at them first - while the
I did look over them. Maybe I'd get the whole thing better if I had a
brief description of each view rather that having to infer the purpose
for myself from an sql statement of a list of fields. If you're
concerned to make a case I think that would be useful. If that's been
published and I
FWIW, I don't see the issue as internal vs external at all. What's
bothering me is whether these views can be considered sufficiently
more stable and better designed than the physical system catalogs
to justify recommending that application designers should rely on
the views instead of the
Merlin Moncure [EMAIL PROTECTED] writes:
Argument 3: backwards compatibility. Do you remember how tablespaces
introduction broke pgAdmin?
This argument, at least, is bogus. See my original comments to Josh:
it is not credible that these views will be significantly more stable
than the
On Thu, May 12, 2005 at 01:23:17AM -0400, Tom Lane wrote:
Thomas F. O'Connell [EMAIL PROTECTED] writes:
I think it's important to consider the perspective of both developers
and users, and the internal views clearly creates issues for the
developers.
FWIW, I don't see the issue as
[EMAIL PROTECTED] (elein) writes:
Also, if you do not trust the newsysview team to develop good views
(with input for hackers), how can you possibly expect every dba and tool
maker to access the system catalog in a consistent and accurate manner.
I never said that they couldn't develop useful
Tom,
I never said that they couldn't develop useful views. I do question
the assumption that they can be all things to all people. I think the
claims being made in this thread are highly overblown. In particular
I doubt that views that expose everything anyone might want to know
are going
On Thu, May 12, 2005 at 03:30:59PM -0400, Tom Lane wrote:
[EMAIL PROTECTED] (elein) writes:
Also, if you do not trust the newsysview team to develop good views
(with input for hackers), how can you possibly expect every dba and tool
maker to access the system catalog in a consistent and
Josh Berkus wrote:
1) would some kind of new system views in theory be valuable and accepted
I still don't have any strong views, but I do want the target audience
specified - I have seen conflicting messages on that. Power users? Admin
Tool builders? Client library builders? These groups
On Thursday 12 May 2005 01:32, Christopher Kings-Lynne wrote:
FWIW, I don't see the issue as internal vs external at all. What's
bothering me is whether these views can be considered sufficiently
more stable and better designed than the physical system catalogs
to justify recommending
Andrew,
I still don't have any strong views, but I do want the target audience
specified - I have seen conflicting messages on that. Power users? Admin
Tool builders? Client library builders? These groups don't all have the
same needs.
DBAs, tool builders (primarily
On Thu, May 12, 2005 at 05:52:43PM -0400, Robert Treat wrote:
On Thursday 12 May 2005 01:32, Christopher Kings-Lynne wrote:
FWIW, I don't see the issue as internal vs external at all.
What's bothering me is whether these views can be considered
sufficiently more stable and better
As lead phpPgAdmin developer, I'm officially in favour of them. The
main reason being all the extra fruit they have that shows database
size, etc.
As non-lead phpPgAdmin developer, I'd be against using them in phppgadmin.
(note this doesnt mean I am against them in pgsql itself)
Hehe, talk about
Christopher Kings-Lynne wrote:
As lead phpPgAdmin developer, I'm officially in favour of them. The
main reason being all the extra fruit they have that shows database
size, etc.
As non-lead phpPgAdmin developer, I'd be against using them in
phppgadmin. (note this doesnt mean I am against them
On Thursday 12 May 2005 19:59, David Fetter wrote:
On Thu, May 12, 2005 at 05:52:43PM -0400, Robert Treat wrote:
On Thursday 12 May 2005 01:32, Christopher Kings-Lynne wrote:
FWIW, I don't see the issue as internal vs external at all.
What's bothering me is whether these views can be
I guess I'm having difficulty understanding why the system catalogs
themselves and provision of support for information_schema are not
sufficient for what exists in core.
At one point, there was a stored procedure database for Pl/PgSQL. It
seems like a system view service like that could
Thomas, All,
I guess I'm having difficulty understanding why the system catalogs
themselves and provision of support for information_schema are not
sufficient for what exists in core.
Because you can't answer the question: What tables does user phil have update
permissions on? or How many
To reiterate my point previously: these system views are NOT aimed at the
people on *this* list; they are for the people on the -NOVICE and -GENERAL
lists and IRC and the people who don't yet use PostgreSQL. Please stop
thinking exclusively in terms of whether they would be useful to you,
I'm not thinking exclusively in terms of whether they would be useful
to me, personally. In fact, I'm certain that they would be useful to
me, personally.
What I question is whether they need to be a part of the internal
development of PostgreSQL. To me, CPAN is an integral part of being
Thomas F. O'Connell [EMAIL PROTECTED] writes:
I think it's important to consider the perspective of both developers
and users, and the internal views clearly creates issues for the
developers.
FWIW, I don't see the issue as internal vs external at all. What's
bothering me is whether these
FWIW, I don't see the issue as internal vs external at all. What's
bothering me is whether these views can be considered sufficiently
more stable and better designed than the physical system catalogs
to justify recommending that application designers should rely on
the views instead of the
Folks,
We've meandered a bit on this, so I wanted to summarize the arguments
presented on the new system views to date so that we might have some hope of
consensus before feature freeze.
As I see it, there are 3 main arguments about having the new system views at
all. These obviously need
... thus, as I see it, the *primary* question is in fact argument (2). That
is, is information_schema sufficient, and if not, can it be extended without
breaking SQL standards? Argument (1) did not seem to have a lot of evidence
on the con side, and the strongest argument against (3) is that
information somewhere else.
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-hackers-
[EMAIL PROTECTED] On Behalf Of Joshua D. Drake
Sent: Tuesday, May 10, 2005 10:30 AM
To: Josh Berkus
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Views, views, views: Summary of Arguments
On Tue, May 10, 2005 at 10:21:06AM -0700, Josh Berkus wrote:
Folks,
We've meandered a bit on this, so I wanted to summarize the
arguments presented on the new system views to date so that we might
have some hope of consensus before feature freeze.
As I see it, there are 3 main
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
interface designers who are designing for 3rd-party multi-database
products who are not supporting PostgreSQL yet and will be
unlikely to learn the system tables
There's a scary thought.
So they are willing to learn the new system views, but
On May 11, 2005, at 7:38, Greg Sabino Mullane wrote:
So they are willing to learn the new system views, but not the system
tables? The above seems an argument for I_S, or at least an expanded
I_S.
So... the reason we don't want to expand (not alter) I_S is that it is
a
standard that very few
40 matches
Mail list logo
