Robert Haas wrote:
> On Mon, Apr 20, 2009 at 12:48 PM, Martijn van Oosterhout
> wrote:
>> On Mon, Apr 20, 2009 at 03:48:11PM +0100, Greg Stark wrote:
>>> So in this situation -- I suspect, if any SELinux people want to pipe
>>> up to tell me whether I'm on the right track -- the idea is that you
>
Gregory Stark wrote:
> Tom Lane writes:
>
>> Greg Stark writes:
>>> I think we're talking at cross purposes here. I think Kai Gai's
>>> descriptions make sense if you start with a different set of
>>> assumptions. The idea behind SELinux is that each individual object is
>>> access controlled an
On Mon, Apr 20, 2009 at 12:48 PM, Martijn van Oosterhout
wrote:
> On Mon, Apr 20, 2009 at 03:48:11PM +0100, Greg Stark wrote:
>> So in this situation -- I suspect, if any SELinux people want to pipe
>> up to tell me whether I'm on the right track -- the idea is that you
>> should be able to examin
Hello,
I was digging through the optimizer code and have a question regarding
the edge recombination crossover (ERX) of the GEQO. It might be
completely stupid and therefore I apologize for this in advance.
As far as I understand it, the idea of the ERX is the minimization of
edge failures. When
On Apr 16, 10:52 am, mito wrote:
> By table structure i mean table definition options.
...which includes columns, right?
Sorry, I don't think I can picture what you're trying to do.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
I loaded a copy of a production database into PG 8.4b1 and immediately
saw that all of our queries were significantly slower compared to v8.1.
Some investigation showed that the use of non-IMMUTABLE PL/PGSQL
functions as view columns, when these views are joined with other
views, cause the
On Apr 20, 2009, at 2:27 PM, Eric B. Ridge wrote:
Some investigation showed that the use of non-IMMUTABLE PL/PGSQL
functions as view columns, when these views are joined with other
views, cause the query to be planned poorly.
I'm sorry. I should have said VOLATILE functions. Which is the
KaiGai Kohei writes:
> Heikki Linnakangas wrote:
>> Can't you have a SE-PostgreSQL policy like "disallow ACL_UPDATE on table
>> X for user Y, except when current user is owner of X"?
> It seems to me a quite ad-hoc idea.
That's rather a silly charge to be leveling when your own proposal is
such
2009/4/20 Tom Lane :
> Peter Eisentraut writes:
>> I find this all a bit premature, given that you haven't clearly defined what
>> sort of user-visible functionality you hope to end up implementing.
>
> That sums up my reaction too --- this looks like a solution in search of
> a problem. The hook
2009/4/20 Peter Eisentraut :
> On Monday 20 April 2009 09:52:05 Pavel Stehule wrote:
>> I don't believe so is possible to find other general solution. (or
>> better I didn't find any other solution). Tom has true,
>> transformationHook on expression is expensive. I thing, so hook on
>> function sho
On Mon, Apr 20, 2009 at 03:48:11PM +0100, Greg Stark wrote:
> So in this situation -- I suspect, if any SELinux people want to pipe
> up to tell me whether I'm on the right track -- the idea is that you
> should be able to examine a user superficially and know for certain
> whether he has the abili
On Mon, Apr 20, 2009 at 4:48 PM, Jaime Casanova
wrote:
> Hi,
>
> sorry for sending this one to this list but i can't send it to
> pginstaller-de...@pgfoundry.org and don't know where else to send it
>
> The new auto_explain contrib is missing in the windows installer, is
> that intentional?
It sh
Hi,
sorry for sending this one to this list but i can't send it to
pginstaller-de...@pgfoundry.org and don't know where else to send it
The new auto_explain contrib is missing in the windows installer, is
that intentional?
--
Atentamente,
Jaime Casanova
Soporte y capacitación de PostgreSQL
Ase
Tom Lane writes:
> Greg Stark writes:
>> I think we're talking at cross purposes here. I think Kai Gai's
>> descriptions make sense if you start with a different set of
>> assumptions. The idea behind SELinux is that each individual object is
>> access controlled and each user has credentials wh
Greg Stark writes:
> I think we're talking at cross purposes here. I think Kai Gai's
> descriptions make sense if you start with a different set of
> assumptions. The idea behind SELinux is that each individual object is
> access controlled and each user has credentials which grant access to
> spe
Tom Lane wrote:
However, what seems more worrisome to me is the prospect already
discussed that the codeset name we have in the table is not actually
recognized by gettext/iconv. Did we have a solution for that?
You get English.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb
On Mon, Apr 20, 2009 at 3:14 PM, Tom Lane wrote:
>> It seems to me a quite ad-hoc idea.
>
> That's rather a silly charge to be leveling when your own proposal is
> such a horrid kluge as this one. As near as I can tell, you intend
> that SELinux will be unable to prohibit SELECT FOR UPDATE becaus
Just for information due to server lab reorganization we (Me & Jorgen)
are going to consolidate and transfer our Solaris'es buildfarms member
(moth_*) to a another hardware (another lab). It should be finished
during next couple of weeks. During this time, results could be
confusing.
Thank
Fujii Masao wrote:
On Mon, Apr 20, 2009 at 6:06 PM, Heikki Linnakangas
wrote:
What's wrong with just this: (ignoring the missing fast option)
--- a/contrib/pg_standby/pg_standby.c
+++ b/contrib/pg_standby/pg_standby.c
@@ -552,8 +552,6 @@ main(int argc, char **argv)
break;
Peter Eisentraut writes:
> I find this all a bit premature, given that you haven't clearly defined what
> sort of user-visible functionality you hope to end up implementing.
That sums up my reaction too --- this looks like a solution in search of
a problem. The hook itself might be relatively h
Magnus Hagander writes:
> Tom Lane wrote:
>>> What makes more sense to me is to add a table to encnames.c that
>>> provides the gettext name of every encoding that we support.
> Here's a patch that moves the table over to encnames.c, and renames it
> to look like the others.
I think you forgot t
On Monday 20 April 2009 09:52:05 Pavel Stehule wrote:
> I don't believe so is possible to find other general solution. (or
> better I didn't find any other solution). Tom has true,
> transformationHook on expression is expensive. I thing, so hook on
> function should be simple and fast - not all tr
2009/4/18 Tom Lane :
> Pavel Stehule writes:
>> 2009/4/11 Tom Lane :
>>> No, I was complaining that a hook right there is useless and expensive.
>>> transformExpr() is executed multiple times per query, potentially a very
>>> large number of times per query; so even testing to see if a hook exists
Heikki Linnakangas wrote:
> Andreas Pflug wrote:
>> I've been following the thread with growing lack of understanding why
>> this is so hardly discussed, and I went back to the documentation of
>> what the restore_command should do (
>> http://www.postgresql.org/docs/8.3/static/warm-standby.html )
KaiGai Kohei wrote:
> Tom Lane wrote:
>> KaiGai Kohei writes:
>>> The vanilla access control mechanism switches the current userid, and it
>>> enables
>>> to run SELECT FOR SHARE without ACL_UPDATE, but SELinux's security model
>>> does not
>>> have a concept of ownership.
>> Should I not read t
Andreas Pflug wrote:
I've been following the thread with growing lack of understanding why
this is so hardly discussed, and I went back to the documentation of
what the restore_command should do (
http://www.postgresql.org/docs/8.3/static/warm-standby.html )
While the algorithm presented in the
On Sat, 2009-04-18 at 08:32 -0400, Tom Lane wrote:
> The issues that I think would be worth having tests for are
> questions like "will the planner push comparisons to constants down
> through a full join?" (which was the bug that started this thread).
Yes, that sounds good.
> With a test meth
On Mon, Apr 20, 2009 at 1:38 AM, Tom Lane wrote:
> Pavel Golub writes:
>> Here the patch to /src/include/pg_config_os.h attached improving
>> Borland C++ Compiler compatibility.
>
> Applied along with your other two patches. Please note in future that
> pg_config_os.h is a derived file --- this
Heikki Linnakangas wrote:
> KaiGai Kohei wrote:
>> Tom Lane wrote:
>>> KaiGai Kohei writes:
The vanilla access control mechanism switches the current userid, and it
enables
to run SELECT FOR SHARE without ACL_UPDATE, but SELinux's security model
does not
have a concept o
2009/4/20 Peter Eisentraut :
> On Sunday 19 April 2009 20:47:37 Pavel Stehule wrote:
>> 2009/4/19 Peter Eisentraut :
>> > On Saturday 18 April 2009 18:09:00 Pavel Stehule wrote:
>> >> There are lot of things, that should be done with current grammar only
>> >> on transformation stage. Currently pg
On Sunday 19 April 2009 18:54:45 Tom Lane wrote:
> Peter Eisentraut writes:
> > On Monday 13 April 2009 20:18:31 - - wrote:
> >> 1) Functions like char_length() or length() do NOT return the number
> >> of characters (the manual says they do), instead they return the
> >> number of code points.
>
On Sunday 19 April 2009 20:47:37 Pavel Stehule wrote:
> 2009/4/19 Peter Eisentraut :
> > On Saturday 18 April 2009 18:09:00 Pavel Stehule wrote:
> >> There are lot of things, that should be done with current grammar only
> >> on transformation stage. Currently pg do it now. There are lot of
> >> ps
On Monday 20 April 2009 01:35:25 Robert Grabowski wrote:
>I found some inconsistency on WITH keyword:
Yes, there are lots of those. Deal with it. ;-)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpr
Hi,
On Mon, Apr 20, 2009 at 6:06 PM, Heikki Linnakangas
wrote:
> Fujii Masao wrote:
>>
>> On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao
>> wrote:
>>>
>>> I'd like to propose another simple idea; pg_standby deletes the
>>> trigger file *whenever* the nextWALfile is a timeline history file.
>>> A t
Fujii Masao wrote:
On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao wrote:
I'd like to propose another simple idea; pg_standby deletes the
trigger file *whenever* the nextWALfile is a timeline history file.
A timeline history file is restored at the end of recovery, so it's
guaranteed that the trig
Heikki Linnakangas wrote:
> Magnus Hagander wrote:
>> Tom Lane wrote:
>>> Magnus Hagander writes:
Tom Lane wrote:
> What makes more sense to me is to add a table to encnames.c that
> provides the gettext name of every encoding that we support.
Do you mean a separate table there,
36 matches
Mail list logo
