On Tue, Mar 18, 2014 at 09:31:06AM +0100, Ronan Dunklau wrote:
> Le mardi 18 mars 2014 03:54:19 Kouhei Kaigai a écrit :
> > > (1) To acquire the old tuple for UPDATE/DELETE operations, the patch
> > > closely
> parallels our handling for INSTEAD OF triggers on views. It
> > > adds a wholerow resj
On Fri, Mar 21, 2014 at 06:59:05PM +, Simon Riggs wrote:
> On 21 March 2014 18:26, Robert Haas wrote:
>
> >> Given the minor symptoms in released versions, I lean against a back-patch.
> >
> > FWIW, I'd lean toward a back-patch. It's probably not a big deal
> > either way, but I have a hard
On Sat, Mar 22, 2014 at 1:17 PM, Amit Kapila wrote:
> On Wed, Feb 26, 2014 at 11:56 AM, Yugo Nagata wrote:
>> Thanks for your a lot of comments. I revised the patch according to
>> comments from Robert Haas and Marti Raudsepp.
>
> I have started looking into this patch and below are my
> initial
On Tue, Dec 17, 2013 at 09:37:09AM -0500, Robert Haas wrote:
> > Patch attached.
>
> I vote for showing it only with +, but regardless of whether the value
> matches the expected default. I'd keep the relkind test, though,
> because I think I noticed that it currently shows up for indexes,
> whic
On Sat, Mar 22, 2014 at 5:22 PM, Bruce Momjian wrote:
> What did you decide about hashing values in indexes vs. putting them in
> literally?
There are two GIN opclasses supplied. There is a default, which
supports more operators (various "existence" operators - see the
documentation). There is an
On Sat, Mar 22, 2014 at 01:53:06PM -0700, Peter Geoghegan wrote:
> Attached is v12. I think I've brought this as far as I can.
>
> This is mostly just bug fixes, and some additional refactoring. I've
> incorporated Andres' feedback. The only points that I think worth
> noting are:
>
> * The docum
On 22 March 2014 16:28, Jim Nasby wrote:
> On 3/21/14, 7:59 PM, Vik Fearing wrote:
>>
>> On 03/22/2014 01:43 AM, Thom Brown wrote:
>>>
>>> Hi,
>>>
>>> I've created a table with 1000 partial indexes. Each one matches
>>> exactly one row based on the predicate WHERE id = .
>>>
>>> However, when I p
On 3/21/14, 4:54 PM, Tom Lane wrote:
Merlin Moncure writes:
There is no way for psql to handle that case though unless you'd strip
*all* BOMs encountered. Compounding this problem is that there's no
practical way AFAIK to send multiple file to psql via single command
line invocation. If you p
On 2/26/14, 9:15 AM, Simon Riggs wrote:
On 26 February 2014 13:38, Andres Freund wrote:
>Hi,
>
>On 2014-02-26 07:32:45 +, Simon Riggs wrote:
>> >* This definitely should include isolationtester tests actually
>> > performing concurrent ALTER TABLEs. All that's currently there is
>> > t
On 3/21/14, 7:59 PM, Vik Fearing wrote:
On 03/22/2014 01:43 AM, Thom Brown wrote:
Hi,
I've created a table with 1000 partial indexes. Each one matches
exactly one row based on the predicate WHERE id = .
However, when I perform an UPDATE of a single row in a transaction,
I've noticed that all
On 3/21/14, 8:13 PM, David E. Wheeler wrote:
On Mar 21, 2014, at 2:16 PM, Andrew Dunstan wrote:
Surely if it were really a major annoyance, someone would have sent code to fix
it during the last 4 years and more since the above.
I suspect it's a minor annoyance :-)
But by all means add it t
On 03/22/2014 04:00 PM, Tom Lane wrote:
On the other side, coding with the explicit cast helps guard against far
more dangerous coding errors, which the compiler will*not* help you with.
What if myextra is actually of type "int64 *"?
Indeed, neither "gcc -Wall -Wextra -std=c89 -pedantic" nor "cl
Piotr Stefaniak writes:
> Apart from what the page says, I also think of casting malloc() as bad
> style and felt the need to bring this up.
Well, that's a value judgement I don't happen to agree with. Yeah, it'd
be better if the language design were such that we could avoid explicit
casting ev
On 03/22/2014 04:00 PM, Tom Lane wrote:
That argument is entirely bogus, as it considers only one possible way
in which the call could be wrong; a way that is of very low probability
in PG usage, since we include in our core headers. Besides
which, as noted in the page itself, most modern compi
Andrzej Mazurkiewicz writes:
>> So in other words, somebody could (accidentally or maliciously) break the
>> constraint by dropping one of its implementation triggers. I doubt that's
>> acceptable.
> The present postgres behavior ALLOWS accidental or malicious break the
> constraint by dropping
On 22 March 2014 15:04, Tom Lane wrote:
> Thom Brown writes:
>> On 22 March 2014 05:32, Tom Lane wrote:
>>> Yes. You can't determine whether the index needs to get a new entry
>>> without examining its metadata, and that's what the lock is mainly about.
>
>> I see. Why does this apply to delet
Thom Brown writes:
> On 22 March 2014 05:32, Tom Lane wrote:
>> Yes. You can't determine whether the index needs to get a new entry
>> without examining its metadata, and that's what the lock is mainly about.
> I see. Why does this apply to deletes too?
The executor doesn't take locks on inde
Piotr Stefaniak writes:
>>> +myextra = (int *) malloc(sizeof(int));
> Please consider not casting malloc(). See
That code is per project style, and should stay that way.
> http://c-faq.com/malloc/mallocnocast.html
That argument is entirely bogus, as it considers only one possible way
in w
Good Morning.
1. At the beginning some explanations.
I am a lazy person that tries not to reinvent a wheel.
So I try to use postgres way of automatic processing, i. e. automatic removing
dependent objects (which I consider an elegant solution and I really like it).
A a result, I have used the p
On 22 March 2014 05:32, Tom Lane wrote:
> Thom Brown writes:
>> Is it necessary for a partial index that doesn't include the row to be
>> involved in locking?
>
> Yes. You can't determine whether the index needs to get a new entry
> without examining its metadata, and that's what the lock is mai
On Sat, Mar 22, 2014 at 06:22:37AM +0900, MauMau wrote:
> From: "Jeff Janes"
> >Do people really just copy the files from one directory of local
> >storage to
> >another directory of local storage? I don't see the point of that.
>
> It makes sense to archive WAL to a directory of local storage f
> +myextra = (int *) malloc(sizeof(int));
Please consider not casting malloc(). See
http://c-faq.com/malloc/mallocnocast.html
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Feb 26, 2014 at 11:56 AM, Yugo Nagata wrote:
> Thanks for your a lot of comments. I revised the patch according to
> comments from Robert Haas and Marti Raudsepp.
I have started looking into this patch and below are my
initial findings:
1. Dependency is not recorded when to_regclass is u
On 21 March 2014 16:11, Simon Riggs wrote:
>>> + * Be careful to ensure this function is called for Tables and Indexes
>>> only.
>>> + * It is not currently safe to be called for Views because security_barrier
>>> + * is listed as an option and so would be allowed to be set at a level
>>> lower
On 21 March 2014 23:36, Tom Lane wrote:
> Simon Riggs writes:
>> On 21 March 2014 20:58, Noah Misch wrote:
>>> It's not the behavior I would choose for a new product, but I can't see
>>> benefits sufficient to overturn previous decisions to keep it.
>
>> Speechless
>
> The key argument for not "
25 matches
Mail list logo
