(2012/11/25 22:18), Michael Meskes wrote:
> On Sun, Nov 25, 2012 at 08:02:33PM +0800, Chen Huajun wrote:
>> Thanks for your comment,I will add the patch into commitfest later.
>
> No need for that, the patch is already committed to the archive.
Oh,I got it,Thanks!
--
Regards,
Chen Huajun
--
I looked into the problem reported in bug #7703, namely that queries
such as
select distinct min(x) from tab;
fail if "tab" is an inheritance tree and an index-optimized plan
using MergeAppend is possible. What's happening is that
(1) the use of DISTINCT causes us to create an EquivalenceC
Jeff Davis writes:
> Now it tries to keep the VM buffer pinned during scans, inserts,
> updates, and deletes. This should avoid increased contention pinning the
> VM pages, but performance tests are required.
> ...
> Then again, if a 5GB table is being randomly accessed, an extra pin is
> unlikely
pposed to look like.
Regards,
Jeff Davis
rm-pd-all-visible-20121125.patch.gz
Description: GNU Zip compressed data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
oup by checksum % for various
primes, and not seeing any skew), and I didn't see any worrying
patterns.
Regards,
Jeff Davis
replace-tli-with-checksums-20121125.patch.gz
Description: GNU Zip compressed data
checksums-20121125.patch.gz
Description: GNU Zip compressed data
--
Sent vi
On Mon, Nov 26, 2012 at 11:17 AM, Phil Sorber wrote:
> I am going to be unavailable until Wednesday, so maybe gives us a few
> more days for feedback.
>
Sure no problem. Thanks.
--
Michael Paquier
http://michael.otacoo.com
I am going to be unavailable until Wednesday, so maybe gives us a few
more days for feedback.
On Fri, Nov 23, 2012 at 9:48 AM, Michael Paquier
wrote:
>
>
> On Sat, Nov 17, 2012 at 2:48 AM, Phil Sorber wrote:
>>
>> On Thu, Nov 15, 2012 at 10:55 PM, Michael Paquier
>> wrote:
>> > On Fri, Nov 16,
On Sun, Nov 25, 2012 at 7:39 PM, Tom Lane wrote:
> I think this is ignoring the fact that we have an extensible type
> system, and thus a lot more room for problems if we allow too many
> implicit casts.
I don't deny that.
> It might also be worth noting that some of this complexity comes from
>
On Sun, Nov 25, 2012 at 6:46 PM, Tom Lane wrote:
> Robert Haas writes:
> I think we're talking past each other here. It is unarguable that
> (as long as there's only one LPAD function) there is only one possible
> non-error interpretation. However, you are ignoring the real
> possibility that p
On Sun, Nov 25, 2012 at 7:36 PM, Peter Geoghegan wrote:
> On 26 November 2012 00:24, Robert Haas wrote:
>> I remember this sort of thing un-fondly from my C++ days, but it
>> doesn't make me like our current behavior any better.
>
> You can also make a constructor with a single argument "explicit
Robert Haas writes:
> So I think the answer to your question is probably no, purely on the
> grounds that we have set a new world record for byzantine casting
> systems. A more fair comparison might be to look at what other SQL
> systems allow. Oracle, MySQL, and SQL Server all permit implicit
On 26 November 2012 00:24, Robert Haas wrote:
> I remember this sort of thing un-fondly from my C++ days, but it
> doesn't make me like our current behavior any better.
You can also make a constructor with a single argument "explicit", and
thereby prevent implicit conversions. So yes, C++ disting
Hi Kevin,
On 15/11/2012 03:28, Kevin Grittner wrote:
Attached is a patch that is still WIP but that I think is getting
pretty close to completion.
I've been looking at this, but I unfortunately haven't had as much time
as I had hoped for, and have not looked at the code in detail yet. It's
On Sun, Nov 25, 2012 at 7:05 PM, Peter Geoghegan wrote:
> Well, you can make your class copy-constructable by providing a
> constructor (and a copy-assignment operator) whose only argument is,
> say, an int. In additional to that, you could potentially define a
> conversion operator, which will ma
On Sun, Nov 25, 2012 at 6:46 PM, Tom Lane wrote:
> I think we're talking past each other here. It is unarguable that
> (as long as there's only one LPAD function) there is only one possible
> non-error interpretation. However, you are ignoring the real
> possibility that perhaps the situation *i
On 25 November 2012 23:31, Robert Haas wrote:
> The only other programming
> language I know of in which you can define what it means to cast
> between two data types is C++, and it's not generally considered one
> of that languages better features. AFAICT, they have implicit casts
> and explicit
Robert Haas writes:
> On Thu, Nov 22, 2012 at 10:17 AM, Tom Lane wrote:
>> The argument here is basically between ease of use and ability to detect
>> common programming mistakes. It's not clear to me that there is any
>> principled way to make such a tradeoff, because different people can
>> re
> I'd be fine with that if we had a system that allows users to pick the
> behavior that they want in their particular environment, but in fact
> our existing system is extremely inflexible. If you start adding
> additional implicit casts to the system, you get failures trying to
> invoke commonl
On Thu, Nov 22, 2012 at 10:17 AM, Tom Lane wrote:
> The argument here is basically between ease of use and ability to detect
> common programming mistakes. It's not clear to me that there is any
> principled way to make such a tradeoff, because different people can
> reasonably put different weig
On Wed, Nov 21, 2012 at 5:10 PM, Peter Eisentraut wrote:
> Because a strongly-typed system should not cast numbers to strings
> implicitly. Does the equivalent of the lpad case work in any other
> strongly-typed programming language?
Does any other strongly-typed programming language distinguish
On Sat, Nov 24, 2012 at 6:01 PM, Peter Eisentraut wrote:
> On Wed, 2012-11-21 at 15:12 -0500, Robert Haas wrote:
>> On Sat, Nov 17, 2012 at 1:22 AM, Peter Eisentraut wrote:
>> > On Mon, 2012-11-12 at 11:42 -0600, Karl O. Pinc wrote:
>> >> Could ALTER TABLE use an option to drop the
>> >> primary
Hi!
On Wed, Nov 21, 2012 at 12:51 AM, Pavel Stehule wrote:
> do you plan to support GiST?
>
At first, I would note that pg_trgm GiST opclass is quite ridiculous for
support regex search (and, actually for LIKE/ILIKE search which is already
implemented too). Because in GiST opclass we store set o
On Tue, Nov 20, 2012 at 1:43 PM, Heikki Linnakangas wrote:
> Glad to see this patch hasn't been totally forgotten. Being able to use
> indexes for regular expressions would be really cool!
>
> Back in January, I asked for some high-level description of how the
> algorithm works (http://archives.p
On Sun, Nov 25, 2012 at 08:02:33PM +0800, Chen Huajun wrote:
> Thanks for your comment,I will add the patch into commitfest later.
No need for that, the patch is already committed to the archive.
> It maybe my first patch for open source.
It definitely is then.
Michael
--
Michael Meskes
Michae
> How on earth did you run into this? :)
ooh, first I saw the code accidentally,it looks a bit dangerous and differents
from the function ECPGdump_a_simple() above,
And then I tried to write a test to raise some errors.
Thanks for your comment,I will add the patch into commitfest later.
It mayb
25 matches
Mail list logo
