> 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
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 project
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 nee
On 2005-05-13, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
> Josh Berkus wrote:
>>Doesn't it seem like a really complete set of system views (based on
>>information_schema or otherwise) would potentially allow securing the
>>pg_catalog?
>
> Not really, no. It would just be one more thing that my ha
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 safe
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 sy
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 see
Josh Berkus 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 would be
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
> w
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 woul
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.
> >
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
"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
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 significa
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
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 vie
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 i
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
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 bet
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 existing-tool-integrat
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 recomme
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 don
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
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 g
[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 usef
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 th
"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 un
> 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
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 catal
"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 wheth
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
a
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,
per
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 ma
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 easily
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 R
-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 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 ar
additional
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]
... 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 tha
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
40 matches
Mail list logo
