On Fri, Jul 9, 2010 at 10:25 PM, Boxuan Zhai wrote:
> Dear All,
>
> This is ZHAI BOXUAN, a student of gSoC 2010. My project is to add merge
> command in postgres.
>
> This is the first submission of our codes, which has finished the parser,
> analyzer and rewriter parts.
>
> If you are interested
1;2401;0cOn Fri, Jul 09, 2010 at 06:49:27PM -0400, Alvaro Herrera wrote:
> Excerpts from Tom Lane's message of vie jul 09 12:16:42 -0400 2010:
>
> > If anybody feels really uncomfortable with that, we could add a
> > compensating "Assert(IsBinaryCoercible(ARR_ELEMTYPE(statarray),
> > atttype))" int
Alvaro Herrera writes:
> Excerpts from Tom Lane's message of vie jul 09 12:16:42 -0400 2010:
>> If anybody feels really uncomfortable with that, we could add a
>> compensating "Assert(IsBinaryCoercible(ARR_ELEMTYPE(statarray),
>> atttype))" into get_attstatsslot(). Not sure if it's worth the cycl
Excerpts from Tom Lane's message of vie jul 09 12:16:42 -0400 2010:
> If anybody feels really uncomfortable with that, we could add a
> compensating "Assert(IsBinaryCoercible(ARR_ELEMTYPE(statarray),
> atttype))" into get_attstatsslot(). Not sure if it's worth the cycles.
Cycles spent only in as
Simon Riggs writes:
> On Fri, 2010-07-09 at 14:01 -0400, Tom Lane wrote:
>> Consider PREPARE followed only later by EXECUTE. Your proposal would
>> make the PREPARE fail outright, when it currently does not.
> Just to avoid wasted investigation: are you saying that is important
> behaviour that
2010/6/14 KaiGai Kohei :
> The attached patch tries to rework DML permission checks.
>
> It was mainly checked at the ExecCheckRTEPerms(), but same logic was
> implemented in COPY TO/FROM statement and RI_Initial_Check().
>
> This patch tries to consolidate these permission checks into a common
> f
On Fri, Jul 9, 2010 at 4:06 PM, Peter Eisentraut wrote:
> On ons, 2010-07-07 at 16:37 +0100, Mike Fowler wrote:
>> Here's the patch to add the 'xml_is_well_formed' function.
>
> I suppose we should remove the function from contrib/xml2 at the same
> time.
Yep.
--
Robert Haas
EnterpriseDB: http:
On Fri, Jul 9, 2010 at 4:10 PM, Yeb Havinga wrote:
> Joshua D. Drake wrote:
>> On Fri, 2010-07-09 at 16:57 +0200, Yeb Havinga wrote:
>>> Hello list,
>>>
>>> Due to dependency requirements my development machine has ubuntu
>>> repositories jaunty, lucid and intrepid.
>>
>> I would not expect anythi
Joshua D. Drake wrote:
On Fri, 2010-07-09 at 16:57 +0200, Yeb Havinga wrote:
Hello list,
Due to dependency requirements my development machine has ubuntu
repositories jaunty, lucid and intrepid.
I would not expect anything to work in an environment that is that
misconfigured. I wou
On ons, 2010-07-07 at 16:37 +0100, Mike Fowler wrote:
> Here's the patch to add the 'xml_is_well_formed' function.
I suppose we should remove the function from contrib/xml2 at the same
time.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscripti
2010/7/8 Pavel Baroš :
> Description of patch:
> 1) can create MV, and is created uninitialized with data
> CREATE MATERIALIZED VIEW mvname AS SELECT ...
This doesn't seem acceptable. It should populate it on creation.
> 2) can refresh MV
> ALTER MATERIALIZED VIEW mvname REFRESH
>
> 3) MV ca
On Fri, Jul 9, 2010 at 1:18 PM, Simon Riggs wrote:
> On Fri, 2010-07-09 at 13:04 -0400, Robert Haas wrote:
>> Tom asked what happens when two transactions attempt to do concurrent
>> actions on the same table. Your response was that we should handle it
>> like CREATE INDEX, and handle the update
On Fri, 2010-07-09 at 14:01 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Fri, 2010-07-09 at 13:21 -0400, Tom Lane wrote:
> >> Except that it *is* a change in behavior: the first check will occur
> >> too soon.
>
> > Sooner matters why?
>
> Consider PREPARE followed only later by EXECUTE.
On Fri, 2010-07-09 at 16:57 +0200, Yeb Havinga wrote:
> Hello list,
>
> Due to dependency requirements my development machine has ubuntu
> repositories jaunty, lucid and intrepid.
>
I would not expect anything to work in an environment that is that
misconfigured. I would suggest running Virtual
Simon Riggs writes:
> On Fri, 2010-07-09 at 13:21 -0400, Tom Lane wrote:
>> Except that it *is* a change in behavior: the first check will occur
>> too soon.
> Sooner matters why?
Consider PREPARE followed only later by EXECUTE. Your proposal would
make the PREPARE fail outright, when it curren
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
> This is certainly true, but I also wonder what SE-PostgreSQL plans to
> do about this. Taking this to its logical exteme, the system security
> policy could change in mid-query - and while you'd like to think that
> the system would stop emit
On Fri, 2010-07-09 at 13:21 -0400, Tom Lane wrote:
> > Agreed that permission checks should logically be applied at
> execution
> > time. I am proposing a performance optimisation, not a change in
> > behaviour.
>
> Except that it *is* a change in behavior: the first check will occur
> too
> soon.
On Fri, Jul 9, 2010 at 1:21 PM, Tom Lane wrote:
> Simon Riggs writes:
>> On Fri, 2010-07-09 at 11:09 -0400, Tom Lane wrote:
>>> Simon Riggs writes:
Strangely, I was looking into removing the ExecCheckRTPerms check
altogether by forcing plan invalidation when permissions are updated.
>>
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Simon Riggs writes:
> > Agreed that permission checks should logically be applied at execution
> > time. I am proposing a performance optimisation, not a change in
> > behaviour.
>
> Except that it *is* a change in behavior: the first check will occur too
On Fri, 2010-07-09 at 13:04 -0400, Robert Haas wrote:
> Tom asked what happens when two transactions attempt to do concurrent
> actions on the same table. Your response was that we should handle it
> like CREATE INDEX, and handle the update of the pg_class row
> non-transactionally. But of cours
Simon Riggs writes:
> On Fri, 2010-07-09 at 11:09 -0400, Tom Lane wrote:
>> Simon Riggs writes:
>>> Strangely, I was looking into removing the ExecCheckRTPerms check
>>> altogether by forcing plan invalidation when permissions are updated.
>>> That would be a performance tweak that would render t
Simon,
* Simon Riggs (si...@2ndquadrant.com) wrote:
> With respect, there doesn't seem to be much use case anyway. I'm sorry
> to be expressing that opinion now; been away for a while. I am somewhat
> amazed that Tom isn't dancing on your head for proposing it though.
I believe it's because we've
On Fri, 2010-07-09 at 11:09 -0400, Stephen Frost wrote:
> > Strangely, I was looking into removing the ExecCheckRTPerms check
> > altogether by forcing plan invalidation when permissions are
> updated.
> > That would be a performance tweak that would render this change
> useless.
>
> I don't see h
On Fri, 2010-07-09 at 11:07 -0400, Robert Haas wrote:
> On Fri, Jul 9, 2010 at 10:51 AM, Simon Riggs
> wrote:
> > The loadable module doesn't "gain control" here it simplify kicks-in
> > after, and in addition to, normal checking. That just means you have
> the
> > option of failing for additional
On Thu, Jul 8, 2010 at 5:09 PM, Simon Riggs wrote:
> On Thu, 2010-07-08 at 06:08 -0400, Robert Haas wrote:
>> On Thu, Jul 8, 2010 at 2:16 AM, Simon Riggs wrote:
>> > On Wed, 2010-07-07 at 22:26 -0400, Robert Haas wrote:
>> >> Rereading the thread, I'm a bit confused by why we're proposing to use
On Fri, 2010-07-09 at 11:09 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > Strangely, I was looking into removing the ExecCheckRTPerms check
> > altogether by forcing plan invalidation when permissions are updated.
> > That would be a performance tweak that would render this change useless.
>
>
On Fri, 2010-07-09 at 11:07 -0400, Robert Haas wrote:
> > Strangely, I was looking into removing the ExecCheckRTPerms check
> > altogether by forcing plan invalidation when permissions are updated.
> > That would be a performance tweak that would render this change useless.
>
> Huh. Obviously, I
Bernd Helmle writes:
> -- assertion failure
> EXPLAIN SELECT 1 FROM foo WHERE UPPER(value) = 'xyz';
> I tried it back from current -HEAD to 8.3.11 and managed to reproduce it
> everywhere. Non-cassert builds are working correctly, so i'm not sure
> wether this is an over-aggressive assert() or
Mark Kirkwood wrote:
> Purely out of interest, since the old repo is still there, I had a
> quick look at measuring the overhead, using 8.4's pgbench to run
> two custom scripts: one consisting of a single 'SELECT 1', the
> other having 100 'SELECT 1' - the latter being probably the worst
> case
On Fri, Jul 9, 2010 at 11:19 AM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Fri, Jul 9, 2010 at 10:52 AM, Stephen Frost wrote:
>> > Something else which has come up but is related is the ability to
>> > support a "pam_tally"-like function in PG. Basically, the abil
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jul 9, 2010 at 10:52 AM, Stephen Frost wrote:
> > Something else which has come up but is related is the ability to
> > support a "pam_tally"-like function in PG. Basically, the ability to
> > lock users out if they've had too many failed log
Simon Riggs writes:
> Strangely, I was looking into removing the ExecCheckRTPerms check
> altogether by forcing plan invalidation when permissions are updated.
> That would be a performance tweak that would render this change useless.
That seems both pointless and wrong. Permissions checks shoul
* Simon Riggs (si...@2ndquadrant.com) wrote:
> The loadable module doesn't "gain control" here it simplify kicks-in
> after, and in addition to, normal checking. That just means you have the
> option of failing for additional reasons.
Right, additional checks (such as the label) can be done.
> We
On Fri, Jul 9, 2010 at 10:52 AM, Stephen Frost wrote:
> * Stephen Frost (sfr...@snowman.net) wrote:
>> Guess my first thought was that you'd have a database-level label that
>> would be used by SELinux to validate a connection. A second thought is
>> labels for roles. KaiGai, can you provide you
On Fri, Jul 9, 2010 at 10:51 AM, Simon Riggs wrote:
> The loadable module doesn't "gain control" here it simplify kicks-in
> after, and in addition to, normal checking. That just means you have the
> option of failing for additional reasons.
True. We could change it so that the normal checking i
EnterpriseDB asked me to develop the attached patch to reduce the
on-disk size of numeric and to submit it for inclusion in PG 9.1.
After searching the archives, I found a possible design for this by
Tom Lane based on an earlier proposal by Simon Riggs.
http://archives.postgresql.org/pgsql-hackers
Hello list,
Due to dependency requirements my development machine has ubuntu
repositories jaunty, lucid and intrepid.
Today I went testing a patch on a recent PostgreSQL. I had to install
autoconf to configure the patched source. While seeing some other
packages getting installed on the scre
* Stephen Frost (sfr...@snowman.net) wrote:
> Guess my first thought was that you'd have a database-level label that
> would be used by SELinux to validate a connection. A second thought is
> labels for roles. KaiGai, can you provide your thoughts on this
> discussion/approach/problems? I realiz
On Fri, 2010-07-09 at 14:06 +, Robert Haas wrote:
> Log Message:
> ---
> Add a hook in ExecCheckRTPerms().
>
> This hook allows a loadable module to gain control when table permissions
> are checked. It is expected to be used by an eventual SE-PostgreSQL
> implementation, but there ar
On Fri, Jul 9, 2010 at 12:54 AM, Tom Lane wrote:
> Robert Haas writes:
How long should I wait before I start breaking things?
>>>
>>> Did you have any particular breakage in mind?
>
>> Well, you can see for yourself what I've submitted for the next CF.
>
> You might want to hold off on the g
On Thu, May 20, 2010 at 1:33 PM, Tom Lane wrote:
>> As for committing it, I would definitely like to commit the actual
>> hook. If we want the hook without the contrib module that's OK with
>> me, although I generally feel it's useful to have examples of how
>> hooks can be used, which is why I t
2010/7/9 KaiGai Kohei :
> (2010/07/07 11:31), Robert Haas wrote:
>> On Tue, Jul 6, 2010 at 10:18 PM, Tom Lane wrote:
>>> Robert Haas writes:
Obviously not. We don't need to acquire an AccessExclusiveLock to
comment on an object - just something that will CONFLICT WITH an
AccessExc
Consider the following small testcase:
BEGIN;
CREATE OR REPLACE FUNCTION upper(IN varchar, OUT varchar)
LANGUAGE SQL STRICT IMMUTABLE
AS
$$
SELECT pg_catalog.upper($1)::varchar;
$$;
CREATE TABLE foo(value varchar);
INSERT INTO foo SELECT 'helmle' FROM generate_series(1, 1000);
CREATE I
hello
2010/7/9 Takahiro Itagaki :
> 2010/7/8 Pavel Stehule :
>> sorry, attached fixed patch
>
> Make installcheck for contrib/stringfunc is broken.
> Please run regression test with --enable-cassert build.
> test stringfunc ... TRAP:
> FailedAssertion("!(!lc_ctype_is_c())", File: "mbuti
44 matches
Mail list logo
