On Sat, Jan 29, 2005 at 12:01:09AM -0500, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > What about a list,
>
> > GRANT ... ON TABLE table1, table2, ... TO user1, user2, ...;
>
> We already allow a list (and have since at least 7.0).
>
> > It would be good if it was a list of w
Tom Lane <[EMAIL PROTECTED]> writes:
> Greg Stark's thought about a power correction seemed interesting too, though
> again far too optimistic to trust without some good math to back it up.
Fwiw, I'm pretty sure good math is not going to back up my off-the-cuff
algorithm. But I did like the answ
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> What about a list,
> GRANT ... ON TABLE table1, table2, ... TO user1, user2, ...;
We already allow a list (and have since at least 7.0).
> It would be good if it was a list of wildcards.
I'm a bit itchy about allowing wildcards --- it doesn't seem to
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> Spending time on this is silly, IMO, unless there is a technical reason
> why the feature should be replaced.
Well, people can validly have different opinions on how critical it is
to dodge the upcoming patent (and surely whether you live in the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark Wu wrote on July 8, 2004:
> I have spent the past four months on this and I have finished the
> YYpaser, Catalog, trigger creation and some other support functions, I
> am working on trigger execution right now. I expect the project will be
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Read the law... willful vs. unknown infringement are two
> different things.
You can't infringe on a non-existent patent.
> FWIW I've really only been advocating that we don't do the change in a
> patch branch, which I'm afraid the "do nothin
Alvaro Herrera wrote:
> On Fri, Jan 28, 2005 at 09:17:46PM +0100, Matthias Schmidt wrote:
>
> > a) accept some sort of wildcard for the grant on table syntax:
> >GRANT ... ON TABLE schema.*
>
> What about a list,
>
> GRANT ... ON TABLE table1, table2, ... TO user1, user2, ...;
>
> It would
On Fri, Jan 28, 2005 at 09:17:46PM +0100, Matthias Schmidt wrote:
> a) accept some sort of wildcard for the grant on table syntax:
>GRANT ... ON TABLE schema.*
What about a list,
GRANT ... ON TABLE table1, table2, ... TO user1, user2, ...;
It would be good if it was a list of wildcards. No
Josh Berkus writes:
> GRANT SELECT ON ALL, NEW TABLES IN public TO phpuser;
> ... does both.
Ah, I overlooked that part of your message. I think the above probably
doesn't work in bison, but if not we could spell it like
GRANT SELECT ON ALL AND NEW TABLES IN public TO phpuser;
Or just make t
Josh Berkus writes:
> Hmm, what about using, ALL and NEW? i.e.
> GRANT SELECT ON NEW TABLES IN public TO phpuser;
> GRANT SELECT ON ALL TABLES IN public TO phpuser;
That seems good to me. More generally it would be
GRANT perm [,...] ON NEW/ALL TABLES IN schema [,...] TO user [,...]
Tom,
> This however seems a rather whimsical reinvention of the meaning of
> CASCADE. ÂI'm not sure if we really need to support both immediate and
> delayed inheritance of privileges from a schema, but if we do, let's
> please use some other keyword than CASCADE to distinguish the cases.
> Also i
Josh Berkus writes:
> Can't say I like either. I'd prefer:
> GRANT [PERM] ON ALL TABLES IN SCHEMA [schemaname] TO [user];
I agree that this syntax seems more SQL-ish than relying on a wildcard.
> GRANT SELECT, UPDATE, INSERT ON TABLES IN SCHEMA public TO php-user;
> .. would set the defaul
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes:
Tom> The only real solution, of course, is to acquire cross-column
Tom> statistics, but I don't see that happening in the near
Tom> future.
Another approach is a hybrid hashing scheme where we use a hash table
until we run out of mem
"Merlin Moncure" <[EMAIL PROTECTED]> writes:
>> You left out SEQUENCES.
> And views, but he was just listing the acceptable targets to the 'grant'
> command. Basically, views and sequences are treated as tables in this
> respect.
Right. Also, LANGUAGEs do not live within schemas, so they drop o
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
The way buildfarm works is that it should always run on a clean set of
CVS files - i.e. there should no gram.c. We don't even bot6her with
clean, distclean, maintainer-clean and friends - we simply copy the
source directory tree for
Josh Berkus writes:
> Why 10? I'd think we could come up with a slightly less arbitrary number,
Well, it's probably within an order of magnitude of the right thing ;-).
We know we don't want 1, but 100 seems awfully optimistic.
If someone can come up with a more defensible number then I'm all
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> The way buildfarm works is that it should always run on a clean set of
> CVS files - i.e. there should no gram.c. We don't even bot6her with
> clean, distclean, maintainer-clean and friends - we simply copy the
> source directory tree for each run. Th
Kris Jurka <[EMAIL PROTECTED]> writes:
> The proposed change biases towards a hash plan which has no provision for
> spilling to disk. Slow is one thing, but excessive memory usage and
> possibly failing is another thing.
Keep in mind that we are replacing 7.4 code that had a serious tendency
to
> > 1. TABLE
> > 2. DATABASE
> > 3. FUNCTION
> > 4. LANGUAGE
> > 5. SCHEMA
> > 6. TABLESPACE
>
> You left out SEQUENCES.
And views, but he was just listing the acceptable targets to the 'grant'
command. Basically, views and sequences are treated as tables in this
respect.
Merlin
--
On Fri, 28 Jan 2005, Tom Lane wrote:
> you don't GROUP BY unique combinations of columns over huge
> tables --- or at least, you shouldn't expect great performance if you do.
The proposed change biases towards a hash plan which has no provision for
spilling to disk. Slow is one thing, but exce
On Fri, Jan 28, 2005 at 21:17:46 +0100,
Matthias Schmidt <[EMAIL PROTECTED]> wrote:
> Hi everybody,
>
> I thought a little bit on possible GRANT syntax for granting to groups
> of objects.
>
> In general, we have the following entities we can grant permissions to:
>
> 1. TABLE
> 2. DATABASE
>
Matt,
> a) accept some sort of wildcard for the grant on table syntax:
> Â Â GRANT ... ON TABLE schema.*
>
> b) use something like CASCADE for the grant on schema syntax:
> Â Â GRANT ... ON SCHEMA CASCADE
> Â Â In this case the grant on schema's need to swallow the permissions
> Â Â (SELECT, INSER
Tom,
> The only real solution, of course, is to acquire cross-column
> statistics, but I don't see that happening in the near future.
Y'know, that's been on the todo list for a while. Surely someone is inspired
for 8.1/8.2? At least for columns which are indexed together?
> As a short-term
Tom Lane wrote:
Darcy Buskermolen <[EMAIL PROTECTED]> writes:
There looks to be an issue with gram.y as seen in the following 2 FreeBSD6
boxen:
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=herring&dt=2005-01-28%2018:33:43
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=echidna&dt=2005-
Hi everybody,
I thought a little bit on possible GRANT syntax for granting to groups
of objects.
In general, we have the following entities we can grant permissions to:
1. TABLE
2. DATABASE
3. FUNCTION
4. LANGUAGE
5. SCHEMA
6. TABLESPACE
since the requirement is to grant to all objects in a given
Greg Stark <[EMAIL PROTECTED]> writes:
> So why is it any more reasonable for Postgres to assume 0 correlation than any
> other value. Perhaps Postgres should calculate these cases assuming some
> arbitrary level of correlation.
[ shrug... ] Sure, if you want to do the legwork to develop somethin
Darcy Buskermolen <[EMAIL PROTECTED]> writes:
> There looks to be an issue with gram.y as seen in the following 2 FreeBSD6
> boxen:
> http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=herring&dt=2005-01-28%2018:33:43
> http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=echidna&dt=2005-01-28%2018:30:01
T
There looks to be an issue with gram.y as seen in the following 2 FreeBSD6
boxen:
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=herring&dt=2005-01-28%2018:33:43
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=echidna&dt=2005-01-28%2018:30:01
--
Darcy Buskermolen
Wavefire Technologies Corp.
ph:
Tom Lane <[EMAIL PROTECTED]> writes:
> The reason this happens even with stats is that the algorithm for
> estimating the number of groups in a multi-group-column situation
> is basically "take the product of the number of distinct values of
> each grouping column, but clamp to the number of rows
* Tom Lane ([EMAIL PROTECTED]) wrote:
> The only real solution, of course, is to acquire cross-column
> statistics, but I don't see that happening in the near future.
That'd be nice, but sounds like alot of work.
> As a short-term hack, I am thinking that the "clamp to size of table"
> part of th
Robert,
> Read the law... willful vs. unknown infringement are two different
> things.
We're not infringing anything, yet. That's a *pending* patent.
> Um... thats the way our legal system works. You could do that to any
> project if you had a patent they were infringing upon no matter how
> s
I got a complaint from a fellow Red Hatter that PG 8.0 is way slower
than 7.4 on some statistical analysis tasks he was doing. Investigation
showed that the primary problem was selection of Sort/GroupAgg in place
of HashAgg to compute some grouped aggregates. Essentially he was doing
sel
On Fri, 28 Jan 2005, Tom Lane wrote:
Oleg Bartunov writes:
Memory growth stoped at 1.8Gb
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
20458 postgres 15 0 1902m 503m 204m D 5.9 49.7 13:59.61 postmaster
Index-related memory leak maybe? What are the indexes on this tab
Oleg Bartunov writes:
> Memory growth stoped at 1.8Gb
>PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
> 20458 postgres 15 0 1902m 503m 204m D 5.9 49.7 13:59.61 postmaster
Index-related memory leak maybe? What are the indexes on this table,
exactly?
On Fri, 28 Jan 2005, Oleg Bartunov wrote:
On Thu, 27 Jan 2005, Tom Lane wrote:
Oleg Bartunov writes:
Day ago we run 'vacuum verbose analyze;' and now we're observing
strange output (see below). We see many repeated passes through the
table 'usno' and all indices (2).
Nothing strange about it: that
Stephen Frost <[EMAIL PROTECTED]> writes:
> I've been thinking about the performance issues some and have to admit
> that I havn't really come to much of a solution. It seems to me that
> there's two ways to come at the issue:
> a) start from the user:
>...
> b) start from the ACL list:
>
On Thu, 2005-01-27 at 12:51, Josh Berkus wrote:
> We don't *have* to do anything when the patent is granted. When we *have*
> to
> do something is when IBM sends a cease-and-desist letter to a PostgreSQL
> user. Not before.
>
With that attitude we don't have to do anything even then. We hav
Title: RE: [HACKERS] [PATCHES] Merge pg_shadow && pg_group -- UNTESTED
> a) start from the user:
> Search for useroid in pg_auth_members.member
> For each returned role, search for that role in member column
> Repeat until all roles the useroid is in have been found
> [Note: This c
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > Ok. Can I get some help defining what the New Truth will look like
> > then? I understand users and groups pretty well but I'm not 100% sure
> > about roles.
>
> So I'm envisioning something like
[...]
> It mig
Simon Riggs wrote:
Clearly this is a must-fix issue, but I'm wondering exactly where the
check should be enforced. Is it sufficient to check at the time of
CREATE AGGREGATE that the creator has appropriate rights, or do we need
to do it every time the aggregate is used?
Well spotted.
Check should
40 matches
Mail list logo
