Neil Conway <[EMAIL PROTECTED]> writes:
> On Fri, 2004-09-17 at 00:34, Tom Lane wrote:
>> I think Andrew has a point: why aren't they the same issue?
> (Note that we need to support CALL proc(...); in SQL for standards
> compliance in any event.)
Right. I'm thinking we could effectively make the
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Neil Conway wrote:
>> On Thu, 2004-09-16 at 23:24, Bruce Momjian wrote:
>>> It will be applied as soon as one of the PostgreSQL committers reviews
>>> and approves it.
>>
>> does this reflect a change in the patch application procedures?
In my mind this
On Fri, 2004-09-17 at 00:34, Tom Lane wrote:
> I think Andrew has a point: why aren't they the same issue? It would
> certainly be no harder to support
> func( ... );
> as a SQL statement than as something allowed only in plpgsql.
If there's a consensus that it is better to modify the main
Neil Conway wrote:
> On Thu, 2004-09-16 at 23:24, Bruce Momjian wrote:
> > It will be applied as soon as one of the PostgreSQL committers reviews
> > and approves it.
>
> Hey Bruce,
>
> does this reflect a change in the patch application procedures? (i.e. in
> the past the pgpatches list you main
Hello !
I've written a small description of the project I would like to work on,
and since it involves Postgres , decided to ask for a feedback
from the people who can help . Thank you :).
The Problem :
Automate database-oriented development.
Solution : automate representation of relational dat
Josh Berkus <[EMAIL PROTECTED]> writes:
> As said, I discussed this with Gaetano on IRC, and am not sure why things are
> set up the way they are.If a user has permission on a view, shouldn't
> that include permission on any functions executed by the view?If not, why
> not?
See prior disc
Josh Berkus <[EMAIL PROTECTED]> writes:
> As said, I discussed this with Gaetano on IRC, and am not sure why things are
> set up the way they are.If a user has permission on a view, shouldn't
> that include permission on any functions executed by the view?If not, why
> not?
Then all s
On Thu, 16 Sep 2004, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > Interestingly, I *cannot* recreate on the single CPU system and I cannot
> > get abort() to generate a core.
>
> By that do you mean that you don't see any corefile in the DB directory
> when you look after the dus
Folks,
> If the view V use a function F.
>
> In this last case is not enough have the select permisson on V but I have
> to give also the Execution permission on F!!!
As said, I discussed this with Gaetano on IRC, and am not sure why things are
set up the way they are.If a user has permissio
Hi all,
I'm having some problem with permissions on views, I spoke with Josh on IRC
about it and I'm reposting it:
I found a not simmetrical behavior about permission on views and functions.
Let me explain:
If I use the view/table T inside the view V, is enough give the select
permission on view V
"Katsaros Kwn/nos" <[EMAIL PROTECTED]> writes:
> On Wed, 2004-09-15 at 19:51, Tom Lane wrote:
>> You'd be well advised to be doing this sort of hackery in a build with
>> --enable-cassert. That turns on CLOBBER_FREED_MEMORY which makes
>> misuse of freed memory a whole lot more obvious.
> I did
Chris Browne <[EMAIL PROTECTED]> writes:
> We have discovered an interesting locking scenario with Slony-I that
> is pointing to a use for the ability to exclude certain schemas from
> pg_dump.
> The situation is that when a "full" pg_dump kicks off, a Slony-I
> "create sync" event, which expects
Neil Conway <[EMAIL PROTECTED]> writes:
> I'm seeing an intermittent assertion failure while running "make check"
> with current sources.
> TRAP: FailedAssertion("!(TransactionIdFollowsOrEquals(xid,
> RecentXmin))", File:
> "/Users/neilc/pgsql/src/backend/access/transam/subtrans.c", Line: 146)
Michael Glaesemann wrote:
On Sep 16, 2004, at 8:48 PM, Andrew Dunstan wrote:
I am also seeing regular "make check" failures on my test buildfarm
system (FC1, 2.4.22 kernel, cassert turned on):
Mmm :) buildfarm! I like the sound of that! Let us know how it goes, eh?
As you saw, the actual runnin
Gavin Sherry <[EMAIL PROTECTED]> writes:
> Interestingly, I *cannot* recreate on the single CPU system and I cannot
> get abort() to generate a core.
By that do you mean that you don't see any corefile in the DB directory
when you look after the dust settles?
I ran into the same problem yesterday
On Thu, 16 Sep 2004, Dennis Bjorklund wrote:
> > Interestingly, I *cannot* recreate on the single CPU system and I cannot
>
> I've been trying to reproduce it on a single cpu system with fedora 2,
> but no luck.
I spook too soon. After having run it even more times I finally got a
failure as we
Neil Conway <[EMAIL PROTECTED]> writes:
> On Thu, 2004-09-16 at 01:19, Andrew Dunstan wrote:
>> ISTM that this is being done at the wrong level anyway.
> I think these are two distinct issues.
I think Andrew has a point: why aren't they the same issue? It would
certainly be no harder to support
On Wednesday 15 September 2004 18:52, Marc G. Fournier wrote:
> In recognition of his role as lead developer on the internationalization
> front, as well as his invaluble work in both the build and release
> processes, Peter Eisentraut has been invited, and has accepted, to join
> the Core Committe
Mark Gibson <[EMAIL PROTECTED]> writes:
I have an idea, to break pg_dump into functions within PostgreSQL.
Philip Warner wrote:
However, there are some complications because pg_dump is also the
upgrade tool; the backed can only know how to describe itself for the
current dialect of SQL accepted b
On Sep 16, 2004, at 8:48 PM, Andrew Dunstan wrote:
I am also seeing regular "make check" failures on my test buildfarm
system (FC1, 2.4.22 kernel, cassert turned on):
Mmm :) buildfarm! I like the sound of that! Let us know how it goes, eh?
Michael Glaesemann
grzm myrealbox com
On Thu, 16 Sep 2004, Gavin Sherry wrote:
> On Thu, 16 Sep 2004, Neil Conway wrote:
>
> > I can consistently repro this, provided I have the patience to run "make
> > check" enough times. Can anyone else repro the problem?
>
> I've managed to recreate this.
>
> I've tried on two linux 2.4 systems.
I am also seeing regular "make check" failures on my test buildfarm
system (FC1, 2.4.22 kernel, cassert turned on):
sysname | snapshot | status | stage
+-++---
cat | 2004-09-15 15:25:59 | 2 | Check
cat | 2004-09-15 23:27:37 | 0
On Wed, 2004-09-15 at 19:51, Tom Lane wrote:
> You'd be well advised to be doing this sort of hackery in a build with
> --enable-cassert. That turns on CLOBBER_FREED_MEMORY which makes
> misuse of freed memory a whole lot more obvious.
I did this but when I try do create a function the following
On Thu, 16 Sep 2004, Gavin Sherry wrote:
> Interestingly, I *cannot* recreate on the single CPU system and I cannot
I've benn trying to reproduce it on a single cpu system with fedora 2, but
no luck.
If someone wants else to try, don't forget the configure flag
--enable-cassert.
--
/Dennis Bj
On Thu, 16 Sep 2004, Neil Conway wrote:
> I can consistently repro this, provided I have the patience to run "make
> check" enough times. Can anyone else repro the problem?
I've managed to recreate this.
I've tried on two linux 2.4 systems. One way and four way systems.
Interestingly, I *cannot*
I'm seeing an intermittent assertion failure while running "make check"
with current sources. I can usually reproduce the problem at least once
out of every 3 or 4 runs of "make check" on each of two different
machines (one is an 866 mhz iBook running OSX, the other is a dual Xeon
@ 2.8 ghz run
26 matches
Mail list logo
