On Sunday 28 June 2009 20:38:59 Robert Haas wrote:
> The only other use case I can think of for functionality of this type
> is some kind of dashboard view on a system with very long-running
> queries, where you want to see how far you have yet to go on each one
> (maybe to approximate when you can
Merlin Moncure wrote:
> Takahiro wrote:
> > contrib/dblink seems to have no treatments for query cancels.
> > (1) Users need to wait for completion of remote query.
> > (2) PGresult objects will be memory leak.
Here is a patch to fix the issues. I hope the fixes will be ported
to older versions
On Sun, Jun 28, 2009 at 2:21 PM, Robert Haas wrote:
> I think that our dependencies for generated header files (gram.h,
> fmgroids.h, probes.h) are not as good as they could be. What we do
> right now is make src/backend/Makefile rebuild these before recursing
> through its subdirectories. This w
Bernd Helmle wrote:
> --On 26. Juni 2009 13:08:37 +0900 KaiGai Kohei
> wrote:
>
>> * Is the named large object (including fully qualified one) worth?
>>It will enables us to specify a largeobject with human readable
>>identifier string.
>
> I don't understand the notion of this. Does t
On Sun, Jun 28, 2009 at 06:28:32PM -0400, Andrew Dunstan wrote:
>
>
> David Fetter wrote:
>> On Sun, Jun 28, 2009 at 05:27:19PM -0400, Andrew Dunstan wrote:
>>
>>> David Fetter wrote:
>>>
> * Users who come from MySQL every once in a while, annoyed that
> we don't su
David Fetter wrote:
On Sun, Jun 28, 2009 at 05:27:19PM -0400, Andrew Dunstan wrote:
David Fetter wrote:
* Users who come from MySQL every once in a while, annoyed that
we don't support "GRANT ... *" syntax.
I'm missing what's wrong with a wild-card GRANT syn
On Sun, 2009-06-28 at 18:03 -0400, Stephen Frost wrote:
> * David Fetter (da...@fetter.org) wrote:
> > On Sun, Jun 28, 2009 at 05:27:19PM -0400, Andrew Dunstan wrote:
> > > Without a major change in the way we do permissions, it will not
> > > work prospectively. We have no way ATM to store permi
On Sun, 2009-06-28 at 14:38 -0700, David Fetter wrote:
> There have been previous discussions of prospective permissions
> changes. Are we restarting them here?
>
I don't remember seeing anything in those discussions that really
materialized. Can you point me to something that you think is a bet
On Sun, 2009-06-28 at 14:16 -0700, David Fetter wrote:
> > The users I'm targeting with my idea are: * Users who have a fairly
> > simple set of users and permissions, and who want a simple picture
> > of the permissions in their system for reassurance/verification.
>
> I don't know of a case that
* David Fetter (da...@fetter.org) wrote:
> On Sun, Jun 28, 2009 at 05:27:19PM -0400, Andrew Dunstan wrote:
> > Without a major change in the way we do permissions, it will not
> > work prospectively. We have no way ATM to store permissions for an
> > object that does not currently exist.
>
> Th
On Sun, 2009-06-28 at 17:23 -0400, Robert Haas wrote:
> I do to some degree share Tom's worry that this is an idiosyncratic
> solution to a tiny subset of the problem space.
I share the concern. However, I don't know if it's a "tiny subset" or
not; I think we'll have to get some feedback from user
On Sun, Jun 28, 2009 at 05:27:19PM -0400, Andrew Dunstan wrote:
>
>
> David Fetter wrote:
>>
>>> * Users who come from MySQL every once in a while, annoyed that
>>> we don't support "GRANT ... *" syntax.
>>>
>>
>> I'm missing what's wrong with a wild-card GRANT syntax for this
>> case.
>
David Fetter wrote:
* Users who come from MySQL every once in a while, annoyed that we
don't support "GRANT ... *" syntax.
I'm missing what's wrong with a wild-card GRANT syntax for this case.
Without a major change in the way we do permissions, it will not work
prospectively
On Sun, Jun 28, 2009 at 2:07 PM, Jeff Davis wrote:
> I'd like some brief feedback on this idea before I try to make a real
> proposal.
>
> The use case is this:
>
> You have an application with several roles:
> * admin user - owns all the objects related to that application
> * normal user - INSE
On Sun, Jun 28, 2009 at 12:52:54PM -0700, Jeff Davis wrote:
> On Sun, 2009-06-28 at 14:56 -0400, Tom Lane wrote:
> > > I meant for "foo" to be a user. "foo_ro" would be the read-only
> > > version, who has a strict subset of foo's permissions.
> >
> > I see. It seems like rather a complicated (an
On Sun, 2009-06-28 at 14:56 -0400, Tom Lane wrote:
> > I meant for "foo" to be a user. "foo_ro" would be the read-only version,
> > who has a strict subset of foo's permissions.
>
> I see. It seems like rather a complicated (and expensive) mechanism
> for a pretty narrow use-case. It'd only help
Jeff Davis writes:
> On Sun, 2009-06-28 at 14:32 -0400, Tom Lane wrote:
>> Jeff Davis writes:
>>> My idea is to have a "GRANT mask":
>>> CREATE ROLE foo_ro GRANT (SELECT ON TABLE, USAGE ON SCHEMA) FROM foo;
>>
>> You haven't really explained what "foo" is here.
> I meant for "foo" to be a user.
On Sun, 2009-06-28 at 14:32 -0400, Tom Lane wrote:
> Jeff Davis writes:
> > My idea is to have a "GRANT mask":
> > CREATE ROLE foo_ro GRANT (SELECT ON TABLE, USAGE ON SCHEMA) FROM foo;
>
> You haven't really explained what "foo" is here. If it's a single
> object then I don't think this offers a
Jeff Davis writes:
> My idea is to have a "GRANT mask":
> CREATE ROLE foo_ro GRANT (SELECT ON TABLE, USAGE ON SCHEMA) FROM foo;
You haven't really explained what "foo" is here. If it's a single
object then I don't think this offers any leverage. If it's a
placeholder or class representative of
On Sun, 2009-06-28 at 14:12 -0400, Bill Moran wrote:
> It seems to me that you're duplicating the functionality that is already
> possible by using groups. i.e. grant the permissions to the group and
> add users to the group as appropriate.
Take the use case in my email. You would have to grant a
Hi,
I think that our dependencies for generated header files (gram.h,
fmgroids.h, probes.h) are not as good as they could be. What we do
right now is make src/backend/Makefile rebuild these before recursing
through its subdirectories. This works OK for a top-level make, but
if you run make furth
Jeff Davis wrote:
>
> I'd like some brief feedback on this idea before I try to make a real
> proposal.
>
> The use case is this:
>
> You have an application with several roles:
> * admin user - owns all the objects related to that application
> * normal user - INSERT/UPDATE/DELETE plus seque
I'd like some brief feedback on this idea before I try to make a real
proposal.
The use case is this:
You have an application with several roles:
* admin user - owns all the objects related to that application
* normal user - INSERT/UPDATE/DELETE plus sequence usage
* read-only user - for rep
On Fri, Jun 26, 2009 at 3:37 AM, Scara Maccai wrote:
> Hi all,
>
> following the link in
>
> http://wiki.postgresql.org/wiki/Query_progress_indication
>
> but mostly:
>
> http://www.postech.ac.kr/~swhwang/progress2.pdf [1]
>
> I'm trying to write an implementation of the "dne" method in postgresql.
Hi.
Ooops, I forgot adjustment completely to Ralf-san. Although Ralf-san understood
at the time, he demanded to wait very busily sorry.
some infomation. this was due to be contained by 1.6.3/4.
This is build the MinGW + gcc.
http://winpg.jp/~saito/pg_work/OSSP_win32/
as for MS-VC++,
http://w
Hi,
I am trying to build Postgres (8.3.5) from source on Windows XP using Visual
Studio 2005 as per the instructions in the PostgreSQL documentation. The
problem is that the uuild.lib and uuid.h files are not tracable though I have
done the requisite downloads from uuid and ossp link specified
Bruce Momjian schrieb:
Andrew Dunstan wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
Alvaro Herrera wrote:
Andrew Dunstan wrote:
I'm confused. There is a Cygwin member of buildfarm, working quite
happily. Can you point me to the exact patch in question, please? I
tho
27 matches
Mail list logo