On 7/12/2013 7:10 PM, Josh Berkus wrote:
That would hardly be only true of libedit, on Apple.
It's also broken on some Red Hat versions, last I checked.
Last I heard, libedit was completely borked. Here is a report (two years
old) of still broken libedit in Debian:
http://bugs.debian.org/
On Friday, July 12, 2013 10:07 PM Josh Berkus wrote:
On 07/12/2013 06:15 AM, Amit kapila wrote:
>> I generally use windows as dev environment, it hasn't shown these warnings.
>> I shall check in linux and correct the same.
> Really?
Yes.
> Hey, I'm gonna send you a lot of Windows-specific pa
On 07/12/2013 06:31 PM, Tom Lane wrote:
> Josh Berkus writes:
>> I think the current --with-libedit-preferred should go away, and be
>> replaced by a --with-libedit option which throws an error if libedit
>> isn't found.
>
> I'm not sure that will work well on systems where libedit masquerades
>
> Hello Tatsuo,
>
>> For me, the error message is not quite right, because progress == 0
>> case is considered error as well in your patch. I sugges you change
>> the error message something like:
>>
>> "thread progress delay (-P) must be positive number (%s)\n",
>
> Please find atta
Josh Berkus writes:
> I think the current --with-libedit-preferred should go away, and be
> replaced by a --with-libedit option which throws an error if libedit
> isn't found.
I'm not sure that will work well on systems where libedit masquerades
as readline...
TBH, given the number of bugs we've
Josh Berkus writes:
> The root cause of this is that we treat "default TEXT" the same as "real
> TEXT" as a type.
No, we do not do that at all. A NULL is initially of type unknown, and
that is definitely not the same as text. The type resolution rules
treat the two cases differently.
The real
Hackers,
So I've been trying to compile PostgreSQL with libedit instead of
readline on a linux system, because of a bug in readline (will blog
about it later). This took 5 attempts, because of the peculiar nature
of our readline options in configure:
--without-readline
"compile without readline
On Fri, Jul 12, 2013 at 04:32:52PM -0400, Alvaro Herrera wrote:
> Now, should we support the 0.9.6-and-earlier mechanism? My inclination
> is no; even RHEL 3, the oldest supported Linux distribution, uses 0.9.7
> (Heck, even Red Hat Linux 9, released on 2003). To see OpenSSL 0.9.6
> you need to g
On Jul 12, 2013, at 4:29 PM, Noah Misch wrote:
> On Sun, Jul 07, 2013 at 08:15:00PM -0400, Noah Misch wrote:
>> I mildly recommend we reject this patch as such, remove the TODO item, remove
>> the XXX comments this patch removes, and plan not to add more trivial SPI
>> wrappers.
>
> Seeing just
On Sun, Jul 07, 2013 at 08:15:00PM -0400, Noah Misch wrote:
> I mildly recommend we reject this patch as such, remove the TODO item, remove
> the XXX comments this patch removes, and plan not to add more trivial SPI
> wrappers.
Seeing just the one response consistent with that view, done.
--
Noa
On Wed, Jul 10, 2013 at 10:09 PM, Abhijit Menon-Sen
wrote:
> At 2013-07-10 09:47:34 -0700, j...@agliodbs.com wrote:
>>
>> Due to the apparent lack of performance testing, I'm setting this back
>> to "needs review".
>
> The original submission (i.e. the message linked from the CF page)
> includes
Next version:
- cleanup
- regression test
- fix issue reported by johto (invalid values in parallel transactions)
I would like more feedback and comments about the patch, as some parts
may be too hacky.
In particular, is it a problem that I update a pointer to planSlot? In
my patch, it points to tu
Le lundi 8 juillet 2013 21:46:39, Andrew Dunstan a écrit :
> On 07/08/2013 03:40 PM, Josh Berkus wrote:
> > On 07/04/2013 06:18 AM, Andrew Dunstan wrote:
> >> On 07/04/2013 09:14 AM, Cédric Villemain wrote:
> >>> ah yes, good catch, I though .control file were unique per contrib,
> >>> but there ar
Troels Nielsen escribió:
> Hi,
>
> These are the relevant bits from Apache2.4's mod_ssl.
>
> [snip]
So this is basically the same thing the Pg code is doing.
> That code supports at least OpenSSL 0.9.7 and later.
>
> Some explanation for it can be found here:
>
> http://books.google.dk/books?
On 07/12/2013 10:49 AM, Andrew Dunstan wrote:
On 07/12/2013 01:28 PM, Alvaro Herrera wrote:
Josh Berkus wrote:
-- a couple of compromise proposals were made:
a) that reviewers who do actual code modification of the patch get
credited on the feature, and those who just review it get credite
David,
> I have no idea how this mechanism works but ISTM that the planner could, for
> "anyelement", look at where the result of the function call is used and add
> a cast to the function input value to match the desired result type if the
> input type is "undefined".
Well, that's not how "anyel
On 07/12/2013 01:28 PM, Alvaro Herrera wrote:
Josh Berkus wrote:
-- a couple of compromise proposals were made:
a) that reviewers who do actual code modification of the patch get
credited on the feature, and those who just review it get credited at
the bottom of the release notes, or
b) that
Josh Berkus wrote:
> -- a couple of compromise proposals were made:
>
> a) that reviewers who do actual code modification of the patch get
> credited on the feature, and those who just review it get credited at
> the bottom of the release notes, or
>
> b) that all "names" move to a web page on w
Folks,
Well, I didn't get much in the way of "poll" responses for the straw
poll. However, let me sum up:
-- two hackers thought that reviewers didn't deserve any credit at all.
-- of the majority of respondants, things were about evenly split
between people who favored "big list at the end" an
Josh Berkus wrote
> On 07/12/2013 07:28 AM, Benedikt Grundmann wrote:
>> Thanks David,
>>
>> I like the fact that postgres is explicit in it's types. All I'm arguing
>> is that error message is misleading. And that I had a hard time
>> understanding why happened what happened. The part I was mis
Hackers,
This CF will be officially over in 3 days. On the 16th, we will do the
following:
(1) Patches still marked "waiting on author" will become "returned with
feedback".
(2) Patches marked "needs review" will be examined to see if they
received one good review during the CF. If they did, t
On 07/04/2013 06:11 PM, Antonin Houska wrote:
On 07/03/2013 08:32 PM, Tom Lane wrote:
Another possibility would be to keep the optimization, but disable it in
queries that use LATERAL. I don't much care for that though --- seems
too Rube Goldbergish, and in any case I have a lot less faith in t
On 07/12/2013 06:15 AM, Amit kapila wrote:
> I generally use windows as dev environment, it hasn't shown these warnings.
> I shall check in linux and correct the same.
Really? Hey, I'm gonna send you a lot of Windows-specific patches for
testing in the future ...
--
Josh Berkus
PostgreSQL Exper
On 07/12/2013 07:28 AM, Benedikt Grundmann wrote:
> Thanks David,
>
> I like the fact that postgres is explicit in it's types. All I'm arguing
> is that error message is misleading. And that I had a hard time
> understanding why happened what happened. The part I was missing is that
> despite su
There is a small inconsistency:
select time '12:30:57.123456789';
gives
12:30:57.123457
but
select make_time(12, 30, 57.123456789);
gives
12:30:57.123456
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/
On 07/12/2013 09:15 AM, Amit kapila wrote:
guc.c:5187: warning: no previous prototype for 'validate_conf_option'
preproc.y:7746.2-31: warning: type clash on default action: != <>
I generally use windows as dev environment, it hasn't shown these warnings.
Hackers, please take note. Assertion
Thanks David,
I like the fact that postgres is explicit in it's types. All I'm arguing
is that error message is misleading. And that I had a hard time
understanding why happened what happened. The part I was missing is that
despite supporting an any type the necessary type inference is very very
On Fri, Jul 12, 2013 at 8:47 AM, Benedikt Grundmann
wrote:
> A third party application we use generates SQL queries. Here is query it
> generated that broke today and for which I have a hard time arguing that the
> postgres behavior is correct (minimally the error message is confusing):
>
> =# cr
Benedikt Grundmann wrote
> A third party application we use generates SQL queries. Here is query it
> generated that broke today and for which I have a hard time arguing that
> the postgres behavior is correct (minimally the error message is
> confusing):
>
> =# create temporary table foo (b doub
A third party application we use generates SQL queries. Here is query it
generated that broke today and for which I have a hard time arguing that
the postgres behavior is correct (minimally the error message is confusing):
=# create temporary table foo (b double precision );
CREATE TABLE
Time: 40
On Friday, July 12, 2013 12:02 AM Fujii Masao wrote:
On Fri, Jul 5, 2013 at 2:19 PM, Amit Kapila wrote:
> On Wednesday, July 03, 2013 2:58 AM Alvaro Herrera wrote:
>> Amit Kapila escribió:
>>
> I got the following compile warnings.
> guc.c:5187: warning: no previous prototype for 'validate_conf_
Hitoshi Harada wrote:
> After a couple of more attempts trying to break it, I mark this
> as ready to go.
Thanks.
> One small question: why do we use multiple unique indexes if
> exist?
Two reasons.
(1) By only matching up rows which test as equal on all columns
used in primary keys, we c
On Thu, Jul 11, 2013 at 8:34 PM, Peter Eisentraut wrote:
> On 7/11/13 5:55 AM, Magnus Hagander wrote:
>> If it's safe to switch on the old ones as well, it sounds doable. If
>> we need different toolchains, that's going to be a serious pain. Have
>> you verified that it's fine with the old ones as
Hi,
On 2013-07-11 11:53:57 -0700, Jeff Davis wrote:
> On Thu, 2013-07-11 at 10:28 +0200, Andres Freund wrote:
> > There doesn't seem be an explicitly stated rule that we cannot use the
> > syscaches outside of a transaction - but effectively that's required
> > atm.
>
> Aren't there other things
On Tue, Jul 9, 2013 at 12:50 PM, Kevin Grittner wrote:
>
> Thanks again! New patch attached.
>
After a couple of more attempts trying to break it, I mark this as
ready to go. One small question: why do we use multiple unique
indexes if exist? One index isn't enough?
--
Hitoshi Harada
--
S
35 matches
Mail list logo
