On Fri, Oct 7, 2011 at 21:30, Nikhil Sontakke wrote:
> Hi Alex,
>
> I guess we both are in agreement with each other :)
>
> After sleeping over it, I think that check is indeed dead code with this new
> non-inheritable check constraints functionality in place. So unless you have
> some other comme
Robert Haas writes:
> On Oct 8, 2011, at 11:04 AM, Tom Lane wrote:
>> I'm inclined to fix this by changing the test to examine idx_tup_read
>> not idx_tup_fetch. Alternatively, we could have the test force
>> enable_indexonlyscan off. Thoughts?
> No preference.
I ended up doing it the second
It seems that in order to create an object in a given schema, I must
have been granted create privilege on the schema. But in order to drop
that object I require usage privilege.
This means that with the right privilege settings I can create objects
that I cannot subsequently drop, or can drop
On Tue, Sep 27, 2011 at 1:33 AM, Fujii Masao wrote:
>
> Though there is still ongonig discussion, since there is no objection about
> the above two changes, I revised the patch that way. And I fixed the minor
> bug handling the default value of recovery_target_timeline wrongly.
> Attached is the r
On Sat, 2011-10-08 at 12:44 -0700, Jeff Janes wrote:
> When I apply this to head, "make check" fails with:
>
> create type textrange_en_us as range(subtype=text, collation="en_US");
> + ERROR: collation "en_US" for encoding "SQL_ASCII" does not exist
>
> Is this a problem? e.g. will it break
On Sun, Oct 2, 2011 at 12:05 PM, Jeff Davis wrote:
> On Sun, 2011-10-02 at 11:32 +0200, Florian Pflug wrote:
>> Looking at the patch, I noticed that it's possible to specify the default
>> boundaries ([], [), (] or ()) per individual float type with the
>> DEFAULT_FLAGS clause of CREATE TYPE .. AS
On Oct 8, 2011, at 11:52 AM, Tom Lane wrote:
> I'm inclined to do the last part immediately, since there's a
> performance argument for it, and then work on revising the executor
> implementation.
Sounds great. Thanks for working on this.
...Robert
--
Sent via pgsql-hackers mailing list (pgsq
On Oct 8, 2011, at 11:04 AM, Tom Lane wrote:
> I'm inclined to fix this by changing the test to examine idx_tup_read
> not idx_tup_fetch. Alternatively, we could have the test force
> enable_indexonlyscan off. Thoughts?
No preference.
Should we have another counter for heap fetches avoided? S
I'll point to rather different reasoning...
Libpq is not returning tables, or relations, for that matter, but rather the
results of queries.
It is reasonable to expect to know which attributes of a table are or are
not nullable, and that is commonly available as an attribute of
pg_attribute, howe
I tried to review the "Optimizing box_penalty" patch:
https://commitfest.postgresql.org/action/patch_view?id=600
as posted here:
http://archives.postgresql.org/message-id/4e088690.5080...@enterprisedb.com
The patch no longer applies to source code, due to other recent GiST
changes. Parts o
Josh writes:
> [ unhappy about users being able to freely adjust work_mem etc ]
Really, if you're letting users issue arbitrary SQL queries, there
simply isn't any way to prevent them from beating your server into
the ground. I don't think that inserting a hack to prevent specific
configuration
On Sat, 2011-10-08 at 18:43 +0400, Alexander Korotkov wrote:
> I meant that penalty can be determined as sum of difference of old and
> new bounds of range, i.e. penalty = subtype_diff_float(new_lower,
> old_lower) + subtype_diff_float(old_upper, new_upper).
> When we insert [100,200) into [10,+i
On Sat, Oct 08, 2011 at 09:11:08AM +0200, Kohei KaiGai wrote:
> 2011/10/8 Noah Misch :
> > On Sun, Oct 02, 2011 at 07:16:33PM +0200, Kohei KaiGai wrote:
> >> My preference is still also WITH(security_barrier=...) syntax.
> >>
> >> The arguable point was the behavior when a view is replaced without
=?ISO-8859-1?Q?C=E9dric_Villemain?= writes:
> 2011/10/8 Tom Lane :
>> The diff indicates that the idx_scan count advanced but idx_tup_fetch
>> did not, which is not so surprising here because tenk2 hasn't been
>> modified in some time. If the autovacuum daemon managed to mark it
>> all-visible be
I wrote:
> Robert Haas writes:
>> Not really. We have detected a small performance regression when both
>> heap and index fit in shared_buffers and an index-only scan is used.
>> I have a couple of ideas for improving this. One is to store a
>> virtual tuple into the slot instead of building a r
2011/10/8 Tom Lane :
> I notice that several members of the buildfarm have been consistently
> showing the same regression test failure since the index-only scans
> patch went in:
>
> ***
> /home/pgbuildfarm/workdir/HEAD/pgsql.27150/src/test/regress/expected/stats.out
> Sat Oct 8 03:20:05 2
Hello all,
While working on an application I have been developing for about two
years now, I have come across a base-limitation in PostgreSQL for three
separate problems. I was talking with other members of the community
recently and they agreed that the issue has some merit so I thought I
wou
The obvious typos:
,--- I/Alex (Thu, 06 Oct 2011 19:42:13 -0400) *
| (may use pg_attribute.attnotnull on t1, t2, is I didn't see the 'create's.
(may use pg_attribute.attnotnull on t1, t2, if I didn't see the 'create's.
| Now, for this statement, I can easily identify non-nullable col
On 10/07/2011 11:02 PM, Greg Stark wrote:
All that said I think this is far murkier than you all seem to think.
Copyright law is one of the most complex areas of the law and this is
one of the least well defined parts of copyright law.
Hi Greg:
I don't think "we all" think this issue is clea
I notice that several members of the buildfarm have been consistently
showing the same regression test failure since the index-only scans
patch went in:
***
/home/pgbuildfarm/workdir/HEAD/pgsql.27150/src/test/regress/expected/stats.out
Sat Oct 8 03:20:05 2011
---
/home/pgbuildfarm/workdir
On Sat, Oct 8, 2011 at 1:01 PM, Jeff Davis wrote:
> On Fri, 2011-10-07 at 12:54 +0400, Alexander Korotkov wrote:
>
> > The first thing caught my eye in existing GiST code is idea of
> > subtype_float. float8 has limited precision and can't respresent, for
> > example, varlena values good enough.
Julien Tachoires 10/07/11 10:17 AM >>>
> Here's a patch to allow TOAST tables to be moved to a different
> tablespace. This item has been picked up from the TODO list.
> Main idea is to consider that a TOAST table can have its own
> tablespace.
Thanks for the patch. Please add this to the ope
Bruce Momjian wrote:
> OK, I have modified the postmaster in PG 9.2 to allow output of the data
> directory, and modified pg_ctl to use that, so starting in PG 9.2 pg_ctl
> will work cleanly for config-only directories.
>
> I will now work on pg_upgrade to also use the new flag to find the data
>
On Fri, 2011-10-07 at 12:54 +0400, Alexander Korotkov wrote:
> The first thing caught my eye in existing GiST code is idea of
> subtype_float. float8 has limited precision and can't respresent, for
> example, varlena values good enough. Even if we have large int8 value
> we can loose lower bits, b
2011/10/8 Noah Misch :
> On Sun, Oct 02, 2011 at 07:16:33PM +0200, Kohei KaiGai wrote:
>> My preference is still also WITH(security_barrier=...) syntax.
>>
>> The arguable point was the behavior when a view is replaced without
>> explicit WITH clause;
>> whether we should consider it was specified
25 matches
Mail list logo
