Koichi Suzuki wrote:
I believe all the issues pointed out in
http://archives.postgresql.org//pgsql-hackers/2008-10/msg01387.php as
been covered in the current patch, as discussed with Simon. I also
understand that we're running out of time.
I pointed out a few more issues here:
So, I realized that there does not seem to be an easy way for cross
compiling plpython. The configure checks for the locally installed python
include locations and eventually the plpython makefile ends up picking all
the local includes too.
Does anyone have any experiences on cross-compiling
On Monday 16 March 2009 15:55:29 Tino Wildenhain wrote:
Did you check debian source packages? At least I believe they do not
compile everything on the respective system so there must be some hooks
for crosscompiling.
You believe wrongly, unfortunately. Everything is compiled natively.
--
On Tuesday 17 March 2009 05:29:48 Tom Lane wrote:
I wrote:
Well, we could certainly debate the change on its own merits, but
I'm not seeing that it's enough nicer to justify a risk of breaking
ps-watching scripts.
Also, on second thought: what about IPv6 addresses? Colon doesn't
look
On Mon, 2009-03-16 at 21:21 +0200, Heikki Linnakangas wrote:
Jonah H. Harris wrote:
On Mon, Mar 16, 2009 at 3:03 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Someone should raise a support request / whatever they call them with
Oracle to get this fixed on their
On Mon, 2009-03-16 at 14:43 -0400, Jonah H. Harris wrote:
On Mon, Mar 16, 2009 at 2:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm finding it hard to believe that there is no way to
override what
Oracle's client library does --- there are *plenty* of
situations
Tom Lane wrote:
The solution to this is to change the following line in
src/backend/postmaster/postmaster.c:
We're not going to break a bunch of other applications in order to make
some undocumented, unsupported Oracle thingie work (until they change
it...). Got another solution?
Yes
It looks OK now.
Zdenek
Dne 8.03.09 21:58, Robert Lor napsal(a):
2) Maybe
TRACE_POSTGRESQL_SLRU_READPAGE_PHYSICAL_DONE(true, -1, -1);
would be better. Because slru_errcause, slru_errno can contains garbage
in situation when everything goes fine. Same for write.
I've made the
Robert Haas wrote:
Well, we have been working on stuff for the past month so it was not
like we were waiting on SE-PG to move forward.
Stuff related to the CommitFest?
AFAICS, the only committer who has done any significant review or
committing of patches in the last month is Heikki,
Sorry for late answer, I was on vacation last week. I see that you
already fix a problem.
Answer why it happens when probes are disabled is, that for user
application there are piece of code which prepare DTrace probes
arguments which will be passed into kernel DTrace modul. This code has
We added the following commit in 8.4:
/src/backend/utils/adt/datetime.c
tgl
Reject year zero during datetime input, except when it's a 2-digit
year (then it means 2000 AD). Formerly we silently
You are assuming that only commit-fest work is required to get us to
beta. You might remember the long list of open items I faced in January
that I have whittled down, but I still have about twenty left.
Tom has done work fixing optimizer bugs introduced in 8.4. I have had
EnterpriseDB
Robert Haas wrote:
You are assuming that only commit-fest work is required to get us to
beta. ?You might remember the long list of open items I faced in January
that I have whittled down, but I still have about twenty left.
Tom has done work fixing optimizer bugs introduced in 8.4. ?I
It's not like my opinion has any weight but still,
On Tuesday 17 March 2009 16:15:21 Robert Haas wrote:
either make the release happen on time, or we can get all of the
patches reviewed, but we can only do both if the committers have the
time and energy to make that happen. Do you disagree?
About a year ago, you talked to the PostgreSQL people about some problem with
Solaris getopt_long, and they changed the build to use the internal getopt_long
instead of the Solaris one?
What was the problem with Solaris getopt_long? Does the problem still exist in
Solaris 10?
My users are
Hi,
Please ignore this message.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
-
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Tue, Mar 17, 2009 at 3:42 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
-
This email on the web: http://archives.postgresql.org/message-id/$MESSAGE_ID
fail :)
--
greg
-
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Tue, Mar 17, 2009 at 11:18 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
You are assuming that only commit-fest work is required to get us to
beta. ?You might remember the long list of open items I faced in January
that I have whittled down, but I still have about twenty
Greg Stark wrote:
On Tue, Mar 17, 2009 at 3:42 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
-
This email on the web: http://archives.postgresql.org/message-id/$MESSAGE_ID
fail :)
Yeah, majordomo does not consider MESSAGE_ID a standard substitution
variable. It's some other kind
Dne 17.03.09 16:38, Chuck McDevitt napsal(a):
About a year ago, you talked to the PostgreSQL people about some problem
with Solaris getopt_long, and they changed the build to use the internal
getopt_long instead of the Solaris one?
The problem was with getopt which is works little bit
Dne 17.03.09 17:13, Zdenek Kotala napsal(a):
I don’t know if I should revert that change, or port netBSD
getopt_long and replace the PostgreSQL one with that.
getopt_long is OK. Problem is getopt. getopt in core is currently taken
from *BSD but it could be updated.
One possible solution
Greg Stark st...@enterprisedb.com writes:
On Tue, Mar 17, 2009 at 3:42 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
This email on the web: http://archives.postgresql.org/message-id/$MESSAGE_ID
fail :)
It's a bad idea anyway.
regards, tom lane
-
Sent via
Tom Lane wrote:
Greg Stark st...@enterprisedb.com writes:
On Tue, Mar 17, 2009 at 3:42 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
This email on the web:
http://archives.postgresql.org/message-id/$MESSAGE_ID
fail :)
It's a bad idea anyway.
I find it useless, but why do
On Tue, 2009-03-17 at 12:37 -0400, Alvaro Herrera wrote:
Tom Lane wrote:
Greg Stark st...@enterprisedb.com writes:
On Tue, Mar 17, 2009 at 3:42 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
This email on the web:
http://archives.postgresql.org/message-id/$MESSAGE_ID
Dne 17.03.09 17:24, Zdenek Kotala napsal(a):
Dne 17.03.09 17:13, Zdenek Kotala napsal(a):
I don’t know if I should revert that change, or port netBSD
getopt_long and replace the PostgreSQL one with that.
getopt_long is OK. Problem is getopt. getopt in core is currently
taken from *BSD but
Bruce Momjian br...@momjian.us writes:
The problem is that the 2-digit year check is for =2 digits, not
exactly two digits:
...
This leads to some unexpected outputs:
test= select '1-1-0'::date;
date
2000-01-01
We've interpreted that like that
Zdenek Kotala zdenek.kot...@sun.com writes:
[ use Solaris' version of getopt_long ]
The reason not to do that was discussed in this thread:
http://archives.postgresql.org//pgsql-patches/2008-02/msg00075.php
While Chuck is certainly free to build his local copy however he wants,
I don't think
What about the idea of updating our getopt and getopt_long to a more modern
version by porting over netBSD getopt?
The current situation is confusing for users, as psql databasename -p port
type of calls works on almost all platforms, but not on those using the
internal getopt/getopt_long.
Chuck McDevitt cmcdev...@greenplum.com writes:
This is because MAC, BSD and GNU getopt_long permutes the arguments, and our
getopt_long does not.
AFAIK those all work by scribbling on the original argv[] array, a
behavior that seems pretty risky from a portability standpoint.
Since our port/
On Mon, Mar 16, 2009 at 08:50:36PM -0400, Tom Lane wrote:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Hmm, I wonder if you could do something malicious with it.
There are any number of scenarios where exposing the client command-line
contents to other database users
Perhaps I could use the same test pg_status uses to decide PS_USE_CHANGE_ARGV
and PS_USE_CLOBBER_ARGV?
Any obviously, we don't just use ours for platforms with no or broken
getopt_long, since we are talking Solaris (which has a bug in getopt, but
getopt_long works fine)
-Original
Zdenek Kotala zdenek.kot...@sun.com writes:
Answer why it happens when probes are disabled is, that for user
application there are piece of code which prepare DTrace probes
arguments which will be passed into kernel DTrace modul. This code has
performance penalty which depends on number of
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
The problem is that the 2-digit year check is for =2 digits, not
exactly two digits:
...
This leads to some unexpected outputs:
test= select '1-1-0'::date;
date
2000-01-01
We've
Andrew == Andrew Gierth and...@tao11.riddles.org.uk writes:
Andrew I have a patch almost done that adds some obvious but
Andrew currently missing functionality to hstore, specifically the
Andrew ability to construct an hstore from a record, and the ability
Andrew to construct one from a pair
On Mar 14, 2009, at 1:26 PM, Josh Berkus wrote:
Yes, I think aliasing (especially at the table level) would be handy.
We already *have* table aliases. They're called views. What we
don't have is column aliases.
A view is not the same as a table alias. Even if you take into
account the
On Tue, 17 Mar 2009, Alvaro Herrera wrote:
Tom Lane wrote:
Greg Stark st...@enterprisedb.com writes:
On Tue, Mar 17, 2009 at 3:42 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
This email on the web: http://archives.postgresql.org/message-id/$MESSAGE_ID
fail :)
It's a bad idea
Marc G. Fournier wrote:
Why a patch? Why not just:
configset DEFAULT message_footer ENDAAB
-
--
Sent via $LIST mailing list ($l...@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/$LIST
--
Archives URL:
Try that, should be fixed ...
On Tue, 17 Mar 2009, Alvaro Herrera wrote:
Marc G. Fournier wrote:
Why a patch? Why not just:
configset DEFAULT message_footer ENDAAB
-
--
Sent via $LIST mailing list ($l...@postgresql.org)
To make changes to your subscription:
Sorry I see the comment. I'll continue the work to fulfill the comment.
2009/3/17 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
Koichi Suzuki wrote:
I believe all the issues pointed out in
http://archives.postgresql.org//pgsql-hackers/2008-10/msg01387.php as
been covered in the
39 matches
Mail list logo
