Re: Remaining items for 8.4 (was Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1710))

Sorry I see the comment. I'll continue the work to fulfill the comment. 2009/3/17 Heikki Linnakangas : > 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

Re: [HACKERS] Ignore -- testing message-id on footer

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

Re: [HACKERS] Ignore -- testing message-id on footer

Marc G. Fournier wrote: > Why a patch? Why not just: > > configset DEFAULT message_footer < - > -- > Sent via $LIST mailing list ($l...@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/$LIST > -- > Archives URL: > http://archives.postgresql.org/message-

Re: [HACKERS] Ignore -- testing message-id on footer

On Tue, 17 Mar 2009, Alvaro Herrera wrote: Tom Lane wrote: Greg Stark writes: On Tue, Mar 17, 2009 at 3:42 PM, Alvaro Herrera 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 you think it

Re: [HACKERS] Column Aliases WAS: Prepping to break every past release...

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 th

Re: [HACKERS] hstore improvements?

> "Andrew" == Andrew Gierth 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 of arrays. And

Re: [HACKERS] Problem with zero year

Tom Lane wrote: > Bruce Momjian 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 inter

Re: [HACKERS] DTrace probes broken in HEAD on Solaris?

Zdenek Kotala 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 arguments. More s

Re: [HACKERS] Solaris getopt_long and PostgreSQL

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 Message

Re: [HACKERS] Problem with accesing Oracle from plperlu functionwhen using remote pg client.

On Mon, Mar 16, 2009 at 08:50:36PM -0400, Tom Lane wrote: > Heikki Linnakangas 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 represents a security hole, quite >

Re: [HACKERS] Solaris getopt_long and PostgreSQL

Chuck McDevitt 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/ module is only going to

Re: [HACKERS] Solaris getopt_long and PostgreSQL

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. F

Re: [HACKERS] Solaris getopt_long and PostgreSQL

Zdenek Kotala 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 we're going to revert

Re: [HACKERS] Problem with zero year

Bruce Momjian 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 since 7.4,

Re: [HACKERS] Solaris getopt_long and PostgreSQL

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 it

Re: [HACKERS] Ignore -- testing message-id on footer

On Tue, 2009-03-17 at 12:37 -0400, Alvaro Herrera wrote: > Tom Lane wrote: > > Greg Stark writes: > > > On Tue, Mar 17, 2009 at 3:42 PM, Alvaro Herrera > > > wrote: > > >> This email on the web: > > >> http://archives.postgresql.org/message-id/$MESSAGE_ID > > > > > fail :) > > > > It's a bad i

Re: [HACKERS] Ignore -- testing message-id on footer

Tom Lane wrote: > Greg Stark writes: > > On Tue, Mar 17, 2009 at 3:42 PM, Alvaro Herrera > > 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 you think it's a bad idea? I had

Re: [HACKERS] Ignore -- testing message-id on footer

Greg Stark writes: > On Tue, Mar 17, 2009 at 3:42 PM, Alvaro Herrera > 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 pgsql-hackers mailing list (pgsql-hackers@postgr

Re: [HACKERS] Solaris getopt_long and PostgreSQL

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 sho

Re: [HACKERS] Solaris getopt_long and PostgreSQL

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 differ

Re: [HACKERS] Ignore -- testing message-id on footer

Greg Stark wrote: > On Tue, Mar 17, 2009 at 3:42 PM, Alvaro Herrera > 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 of variable it se

Re: [HACKERS] small but useful patches for text search

On Tue, Mar 17, 2009 at 11:18 AM, Bruce Momjian 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 left. >>

Re: [HACKERS] Ignore -- testing message-id on footer

On Tue, Mar 17, 2009 at 3:42 PM, Alvaro Herrera 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: http://www.postgresql.org/mailpr

[HACKERS] Ignore -- testing message-id on footer

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: http://www.postgresql.org/mail

[HACKERS] Solaris getopt_long and PostgreSQL

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 unh

Re: [HACKERS] small but useful patches for text search

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?

Re: [HACKERS] small but useful patches for text search

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

Re: [HACKERS] small but useful patches for text search

> 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 > EnterpriseD

[HACKERS] Problem with zero year

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 interp

Re: [HACKERS] DTrace probes broken in HEAD on Solaris?

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 per

Re: [HACKERS] small but useful patches for text search

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 He

Re: [HACKERS] Additional DTrace Probes

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 c

Re: [HACKERS] Problem with accesing Oracle from plperlu functionwhen using remote pg client.

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?

Re: [HACKERS] Problem with accesing Oracle from plperlu functionwhen using remote pg client.

On Mon, 2009-03-16 at 14:43 -0400, Jonah H. Harris wrote: > On Mon, Mar 16, 2009 at 2:34 PM, Tom Lane 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 where >

Re: [HACKERS] Problem with accesing Oracle from plperlu functionwhen using remote pg client.

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 fi

Re: [HACKERS] Problem with accesing Oracle from plperlu functionwhen using remote pg client.

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

Re: [HACKERS] cross-compiling plpython

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. --

Re: [HACKERS] cross-compiling plpython

> > 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-

Re: Remaining items for 8.4 (was Re: [HACKERS] Updates of SE-PostgreSQL 8.4devel patches (r1710))

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: http://archive