On 1/7/15 8:51 PM, Ali Akbar wrote:
> So now +1 for back-patching this.
Done. Was a bit of work to get it into all the old versions.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Sat, Jan 10, 2015 at 8:32 PM, Peter Geoghegan wrote:
> I also include various bugfixes to approach #2 to value locking (these
> were all previously separately posted, but are now integrated into the
> main ON CONFLICT commit). Specifically, these are fixes for the bugs
> that emerged thanks to
Hello
two years a operator "=>" is marked as deprecated (from PostgreSQL 9.2).
Isn't time to use it for named parameters now (for PostgreSQL 9.5) ?
I am sending a implementation where syntax based on "=>" symbol is second
(but preferred) variant of ":=" syntax .. syntax ":=" will be supported
st
On 12/31/2014 03:00 PM, David Rowley wrote:
hmm, I think it should be changed to int128 then. Pitty int4 was
selected as a name instead of int32 back in the day...
I'm going to mark the patch as waiting on author, pending those two changes.
My view with the size estimates change is that if a c
Hi
here is a proof concept of array_offset function
possible question:
* used comparation "=" or "IS NOT DISTINCT FROM"
In this initial proof concept I used "IS NOT DISTINCT FROM" operator - but
my opinion is not strong in this question. Both has some advantages and
disadvantages.
Regards
Pav
On 17/01/15 13:46, Amit Kapila wrote:
On Sun, Jan 11, 2015 at 1:29 AM, Petr Jelinek mailto:p...@2ndquadrant.com>> wrote:
>
>
> In second patch which implements the TABLESAMPLE itself I changed the
implementation of random generator because when I looked at the code
again I realized the old one
2015-01-16 17:57 GMT+01:00 Jim Nasby :
> On 1/16/15 3:39 AM, Pavel Stehule wrote:
>
>> I am proposing a simple function, that returns a position of element in
>> array.
>>
>
> Yes please!
>
> FUNCTION array_position(anyarray, anyelement) RETURNS int
>>
>
> That won't work on a multi-dimensional a
On Sat, Jan 17, 2015 at 2:24 PM, David Johnston
wrote:
> On Fri, Jan 16, 2015 at 10:19 PM, Amit Kapila
> wrote:
>>
>> On Sat, Jan 17, 2015 at 10:41 AM, David Johnston
>> wrote:
>> > On Fri, Jan 16, 2015 at 10:08 PM, Amit Kapila
>> > wrote:
>> >>
>> >> On Sat, Jan 17, 2015 at 10:02 AM, David G J
Hi,
Sorry for taking long to get back to this...
On 2014-12-21 13:21:56 -0500, Tom Lane wrote:
> The idea I'd been wondering about hinged on the same observation that we
> know the buffer is not pinned (by our process) already, but the mechanics
> would be closer to what we do in resource manager
Alvaro Herrera wrote:
> Michael Paquier wrote:
>
>> As mentioned in $subject, commit 08c33c4 of 2003 has made the
>> following block of code dead in tablefunc.c:1320 because level is
>> incremented to at least 1:
>> /* First time through, do a little more setup */
>>
On Fri, Jan 16, 2015 at 10:56 AM, Alvaro Herrera
wrote:
> So how about something like
>
> #define ALLOCFLAG_HUGE 0x01
> #define ALLOCFLAG_NO_ERROR_ON_OOM 0x02
> void *
> MemoryContextAllocFlags(MemoryContext context, Size size, int flags);
That sounds good, although persona
On 2015-01-17 13:16:18 +0100, Andres Freund wrote:
> I'd also like to see patches that primarily move code around as git diff
> -M -C style diffs (can also be passed to format-patch). That will show
> the file move and then additionally the changes that have been made in
> addition to the rename. T
On Sun, Jan 11, 2015 at 1:29 AM, Petr Jelinek wrote:
>
>
> In second patch which implements the TABLESAMPLE itself I changed the
implementation of random generator because when I looked at the code again
I realized the old one would produce wrong results if there were multiple
TABLESAMPLE statemen
Hi,
FWIW, I find it rather annoying if people attach patchsets as
tarballs. That makes it impossible to look at them in the mailreader
since I really don't have anything reasonable to go on to teach it to
treat it as a set of patches.
I'd also like to see patches that primarily move code around a
On Sat, Jan 17, 2015 at 12:49 PM, Alexander Korotkov
wrote:
> BTW, previous version of patch contained some bugs. Revised version is
> attached.
>
Ooops, it's here.
--
With best regards,
Alexander Korotkov.
gin_fillfactor_5.patch
Description: Binary data
--
Sent via pgsql-hackers mailin
On Fri, Jan 16, 2015 at 8:40 PM, Robert Haas wrote:
> On Thu, Jan 15, 2015 at 7:06 AM, Michael Paquier
> wrote:
> > Alexander Korotkov wrote:
> >> I'm not sure. On the one hand it's unclear why fillfactor should be
> >> different from 9.4.
> >> On the other hand it's unclear why it should be dif
16 matches
Mail list logo
