Re: [HACKERS] A Windows x64 port of PostgreSQL

On Thu, Jul 3, 2008 at 12:39 AM, Tom Lane <[EMAIL PROTECTED]> wrote: > "Ken Camann" <[EMAIL PROTECTED]> writes: >> EMT64/AMD64 is new compared to the older architectures, I >> would guess the older ones predate the time when it became a somewhat >> de facto standard to leave "long int" at 4 bytes,

Re: [HACKERS] PATCH: CITEXT 2.0

"David E. Wheeler" <[EMAIL PROTECTED]> writes: > On Jul 2, 2008, at 09:13, Zdenek Kotala wrote: >> Please, do not type space before asterix: >> char * lcstr, * rcstr -> char *lcstr, *rcstr >> >> and do not put extra space in a brackets >> citextcmp( left, right ) -> citextcmp(left, right) > Okay

Re: [HACKERS] Git Repository for WITH RECURSIVE and others

Hi, From: Abhijit Menon-Sen <[EMAIL PROTECTED]> Subject: Re: [HACKERS] Git Repository for WITH RECURSIVE and others Date: Thu, 3 Jul 2008 09:18:17 +0530 > At 2008-07-03 11:16:49 +0900, [EMAIL PROTECTED] wrote: > > > > # WITH RECURSIVE repository > > % git-clone git://git.postgresql.org/git/~d

Re: [HACKERS] PATCH: CITEXT 2.0

On Jul 2, 2008, at 17:21, Tom Lane wrote: Indeed, but why isn't this code put there as well? Well, actually, that might be the best thing to do with it. But it would be sensible to give it a code review anyway, no? Obviously, I would argue that contrib is a good place for it, hence the pa

Re: [HACKERS] PATCH: CITEXT 2.0

On Jul 2, 2008, at 12:18, Teodor Sigaev wrote: 7) Hash opclass is absent. Hash opclass framework is used for hash join. Thanks. I haven't seen docs on this. The original citext only supports btree, and I don't remember reading about creating a hash opclass in the Douglass book, though I p

Re: [HACKERS] PATCH: CITEXT 2.0

On Jul 2, 2008, at 09:39, Peter Eisentraut wrote: Well, yeah, but that seems a very long way off. In the meantime a lot of people use the existing pgfoundry citext module. Indeed, but why isn't this code put there as well? It could be, but this is *such* a common need (and few even know a

Re: [HACKERS] A Windows x64 port of PostgreSQL

"Ken Camann" <[EMAIL PROTECTED]> writes: > Well actually, let me be as strict as possible because I don't know > the latest C standards very well (I am a C++ programmer). Am I > correct that the standard says that sizeof(size_t) must be > sizeof(void*), and that no compiler has ever said otherwise

Re: [HACKERS] PATCH: CITEXT 2.0

On Jul 2, 2008, at 09:13, Zdenek Kotala wrote: I went through your code and I have following comments/questions: Thanks. I'm on a short family vacation, so it will probably be Monday before I can submit a new patch. I got a few replies below, though. 1) formating Please, do not type spac

Re: [HACKERS] A Windows x64 port of PostgreSQL

On Wed, Jul 2, 2008 at 8:43 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > "Ken Camann" <[EMAIL PROTECTED]> writes: >> Oh I see. Between this and looking again at the warning list, I see >> that it will probably take a lot more work than I thought. There are >> about 450 occurrences of the assumption

Re: [HACKERS] Git Repository for WITH RECURSIVE and others

At 2008-07-03 11:16:49 +0900, [EMAIL PROTECTED] wrote: > > # WITH RECURSIVE repository > % git-clone git://git.postgresql.org/git/~davidfetter/postgresql/.git > Initialized empty Git repository in /home/y-asaba/x/postgresql/.git/ > fatal: The remote end hung up unexpectedly Run git-clone h

Re: [HACKERS] Git Repository for WITH RECURSIVE and others

On Thu, Jul 03, 2008 at 11:16:49AM +0900, Yoshiyuki Asaba wrote: > Hi, > > From: David Fetter <[EMAIL PROTECTED]> > Subject: Re: [HACKERS] Git Repository for WITH RECURSIVE and others > Date: Tue, 24 Jun 2008 07:47:13 -0700 > > > > > With lots of help from Greg Sabino Mullane, I've set up a git >

Re: [HACKERS] DTrace probes.

On Monday 19 May 2008 11:32:28 Theo Schlossnagle wrote: > Howdy, > > I just saw Robert Lor's patch w.r.t. dtrace probes. It looks very > similar in what we've done. We run a nice set of probes in production > here that allow us to track the details of checkpointing and statement > execution. I'v

Re: [HACKERS] Git Repository for WITH RECURSIVE and others

Hi, From: David Fetter <[EMAIL PROTECTED]> Subject: Re: [HACKERS] Git Repository for WITH RECURSIVE and others Date: Tue, 24 Jun 2008 07:47:13 -0700 > > > With lots of help from Greg Sabino Mullane, I've set up a git > > > repository for the WITH RECURSIVE patches on > > >

Re: [HACKERS] pg_dump lock timeout

Dave, Just a few comments regarding your pg_dump lock timeout patch (in general I like the concept and agree with adding it): - No validity checking that the argument passed in has anything to do with a number. The backend will do this, but it strikes me as a bit odd to not

Re: [HACKERS] Location for pgstat.stat

Decibel! <[EMAIL PROTECTED]> writes: > Leaving the realm of "an easy change", what about periodically (once > a minute?) writing stats to a real table? The ensuing vacuum overhead seems a sufficient reason why not. regards, tom lane -- Sent via pgsql-hackers mailing li

Re: [HACKERS] A Windows x64 port of PostgreSQL

"Ken Camann" <[EMAIL PROTECTED]> writes: > Oh I see. Between this and looking again at the warning list, I see > that it will probably take a lot more work than I thought. There are > about 450 occurrences of the assumption that sizeof(size_t) == > sizeof(int). [ blink... ] There are *zero* occ

Re: [HACKERS] PATCH: CITEXT 2.0

Peter Eisentraut <[EMAIL PROTECTED]> writes: > Am Dienstag, 1. Juli 2008 schrieb Tom Lane: >> Well, yeah, but that seems a very long way off. In the meantime a lot >> of people use the existing pgfoundry citext module. > Indeed, but why isn't this code put there as well? Well, actually, that mig

Re: [HACKERS] Limits of backwards compatibility for psql's \d commands

On Wed, 2008-07-02 at 18:39 -0500, Decibel! wrote: > On Jul 2, 2008, at 1:23 AM, Tom Lane wrote: > > "Joshua D. Drake" <[EMAIL PROTECTED]> writes: > >> Tom Lane wrote: > >>> ... So it's just 7.3 that's worth debating, I think. > > > >> EOL is EOL, why is the question even being asked? > > > > Wel

Re: [HACKERS] Location for pgstat.stat

On Jul 1, 2008, at 3:02 PM, Tom Lane wrote: Magnus Hagander <[EMAIL PROTECTED]> writes: Alvaro Herrera wrote: Well, it doesn't :-) No database or table will be processed until stat entries are created, and then I think it will first wait until enough activity gathers to take any actions at

Re: [HACKERS] Limits of backwards compatibility for psql's \d commands

On Jul 2, 2008, at 1:23 AM, Tom Lane wrote: "Joshua D. Drake" <[EMAIL PROTECTED]> writes: Tom Lane wrote: ... So it's just 7.3 that's worth debating, I think. EOL is EOL, why is the question even being asked? Well, pg_dump still supports servers back to 7.0 (and yes I do test that now an

Re: [HACKERS] [WIP] patch - Collation at database level

Gregory Stark <[EMAIL PROTECTED]> writes: > Out of curiosity, what is a "user-defined collation"? Are there SQL statements > to go around declaring what order code points should be sorted in? That seems > like it would be... quite tedious! Hm, that's a good point. SQL99 has ::=

[HACKERS] WITH RECURSIVE updated to CVS TIP

Folks, Please find patch enclosed, including some documentation. Can we see about getting this in this commitfest? Cheers, David. -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Reme

Re: [HACKERS] [GENERAL] pg crashing

Magnus Hagander <[EMAIL PROTECTED]> writes: >> below this is going to convert \ to /, wouldn't it be clearer to >> describe the path prefix as Global/PostgreSQL: in the first place? > Eh, that shows another bug I think. It should *not* convert the \ in > "Global\", because that one is is interpret

Re: [HACKERS] Working on native Windows x64 version of PostgreSQL

On Wed, Jul 2, 2008 at 10:41 PM, Ken Camann <[EMAIL PROTECTED]> wrote: > Hi everyone. > > For those who have seen my other thread, I have decided to take the > plunge: I am going to try to get PostgreSQL to compile as a native > Windows x64 application (so that it will be able to interface with x64

[HACKERS] Working on native Windows x64 version of PostgreSQL

Hi everyone. For those who have seen my other thread, I have decided to take the plunge: I am going to try to get PostgreSQL to compile as a native Windows x64 application (so that it will be able to interface with x64 DLLs) and I will contribute my changes to the community. As you know, many of

Re: [HACKERS] Commitfest status?

On Tuesday 01 July 2008 17:38:28 Josh Berkus wrote: > On Tue, 01 Jul 2008 16:19:39 -0400 > > Tom Lane <[EMAIL PROTECTED]> wrote: > > Well, it's July 1, and time for another commit fest to begin. > > Do we have all the submitted patches queued up at > > http://wiki.postgresql.org/wiki/CommitFest:20

Re: [HACKERS] A Windows x64 port of PostgreSQL

On Wed, Jul 2, 2008 at 8:32 PM, Ken Camann <[EMAIL PROTECTED]> wrote: > I'd really like to help out with this, but I'm not sure I can work on > a patch even if I change these things for myself. Fixing this code > would touch a lot of important internals in postgres (albeit in a > small way), so my

Re: [HACKERS] Commitfest status?

On Tue, Jul 1, 2008 at 4:19 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > Well, it's July 1, and time for another commit fest to begin. > Do we have all the submitted patches queued up at > http://wiki.postgresql.org/wiki/CommitFest:2008-07 ? we noticed the libpq events (hooks) patch was missing...so

Re: [HACKERS] Auto-explain patch

> Its certainly not useful to *me* in its current form. It would > produce way to much (usless) output. However if it were tied to > log_min_duration_statement so I get auto explains for long running > queries... That would be very useful indeed. Even if it has to > explain everything just to toss

Re: [HACKERS] A Windows x64 port of PostgreSQL

On Wed, Jul 2, 2008 at 9:09 AM, Bernd Helmle <[EMAIL PROTECTED]> wrote: > --On Mittwoch, Juli 02, 2008 07:39:29 -0400 Ken Camann <[EMAIL PROTECTED]> > wrote: > >> I assume it would only really matter if you did this to >> a pointer, and perhaps that is happening somewhere (but I doubt it >> since

Re: [HACKERS] [WIP] patch - Collation at database level

My patch should be "sort of" wrapper that will implement guts for further development (collation at column level) like catalogs, creating collations etc. When creating collation user will be able to choose which function to use (by statement STRCOLFN - not in SQL standard). In the first stage I'll

Re: [HACKERS] PATCH: CITEXT 2.0

I went through your code and I have following comments/questions: one more comment: 7) Hash opclass is absent. Hash opclass framework is used for hash join. -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: htt

Re: [HACKERS] [WIP] patch - Collation at database level

On Wed, Jul 02, 2008 at 07:22:10PM +0100, Gregory Stark wrote: > > Because the SQL spec says so. Also, if we don't put them in schemas, > > we have no nice way to distinguish built-in and user-defined collations, > > which creates a problem for pg_dump. > > Out of curiosity, what is a "user-defin

Re: [HACKERS] [WIP] patch - Collation at database level

"Tom Lane" <[EMAIL PROTECTED]> writes: > Alvaro Herrera <[EMAIL PROTECTED]> writes: >> Why does a collation have a schema? > > Because the SQL spec says so. Also, if we don't put them in schemas, > we have no nice way to distinguish built-in and user-defined collations, > which creates a problem

Re: [HACKERS] [PATCHES] GIN improvements

Sync with current CVS HEAD and post in hackers- too because patches- close to the closing. http://www.sigaev.ru/misc/fast_insert_gin-0.7.gz http://www.sigaev.ru/misc/multicolumn_gin-0.3.gz -- Teodor Sigaev E-mail: [EMAIL PROTECTED]

Re: [HACKERS] [WIP] patch - Collation at database level

Tom Lane escribió: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > Why does a collation have a schema? > > Because the SQL spec says so. Also, if we don't put them in schemas, > we have no nice way to distinguish built-in and user-defined collations, > which creates a problem for pg_dump. Oh, I

Re: [HACKERS] [WIP] patch - Collation at database level

Alvaro Herrera <[EMAIL PROTECTED]> writes: > Why does a collation have a schema? Because the SQL spec says so. Also, if we don't put them in schemas, we have no nice way to distinguish built-in and user-defined collations, which creates a problem for pg_dump. regards, tom

Re: [HACKERS] WIP patch: reducing overhead for repeat de-TOASTing

Alvaro Herrera <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> It would be simple enough to fix nodeSubplan.c to copy the data into >> an upper-level Slot rather than a bare tuple. But this makes me wonder >> how many other places are like this. In the past there wasn't that much >> benefit to p

Re: [HACKERS] [GENERAL] pg crashing

[moving over to hackers] Tom Lane wrote: > BTW, just looking at win32_shmem.c ... > > retptr = malloc(bufsize + 1 + 18);/* 1 NULL and 18 for >* Global\PostgreSQL: */ > if (retptr == NULL) > elog(FATAL, "could not allocate memory for

Re: [HACKERS] Postgresql 8.3 issue

Am Montag, 30. Juni 2008 schrieb Jamie Deppeler: > I am trying to build a new installer application. > I am in the process of upgrading postgresql 8.1 to 8.3.3 but i am having > a issue which i can't seemed to resolve. > > Error output from rpmbuilder > > + su -c - user'$RPM_BUILD_ROOT/usr/local/ap

Re: [HACKERS] PATCH: CITEXT 2.0

Am Dienstag, 1. Juli 2008 schrieb Tom Lane: > Zdenek Kotala <[EMAIL PROTECTED]> writes: > > However, it will be solved when collation per column will be implemented. > > Well, yeah, but that seems a very long way off. In the meantime a lot > of people use the existing pgfoundry citext module. Ind

Re: [HACKERS] PATCH: CITEXT 2.0

David E. Wheeler napsal(a): Howdy, Howdy Please find attached a patch adding a locale-aware, case-insensitive text type, called citext, as a contrib module. A few notes: I went through your code and I have following comments/questions: 1) formating Please, do not type space before asterix

Re: [HACKERS] [WIP] patch - Collation at database level

Radek Strnad escribió: > 2) What type should all names in CREATE and DROP statement in gram.y have? > I've chosen qualified_name but I know it's not the best choice. I think it should be ColId. > 3) All collations are created from existing collations. How do I ensure that > the collation already

Re: [HACKERS] WIP patch: reducing overhead for repeat de-TOASTing

Tom Lane wrote: > It would be simple enough to fix nodeSubplan.c to copy the data into > an upper-level Slot rather than a bare tuple. But this makes me wonder > how many other places are like this. In the past there wasn't that much > benefit to pulling data from a Slot instead of a bare tuple,

Re: [HACKERS] Location for pgstat.stat

Magnus Hagander <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> It doesn't seem to me that it'd be hard to support two locations for the >> stats file --- it'd just take another parameter to the read and write >> routines. pgstat.c already knows the difference between a normal write >> and a shut

Re: [HACKERS] PATCH: CITEXT 2.0

Yay! Best, David Sent from my iPhone On Jul 2, 2008, at 5:03, Zdenek Kotala <[EMAIL PROTECTED]> wrote: David E. Wheeler napsal(a): On Jul 1, 2008, at 07:38, Tom Lane wrote: However, it will be solved when collation per column will be implemented. Well, yeah, but that seems a very long w

Re: [HACKERS] Location for pgstat.stat

Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: >> Alvaro Herrera wrote: >>> Well, it doesn't :-) No database or table will be processed until stat >>> entries are created, and then I think it will first wait until enough >>> activity gathers to take any actions at all. > >> That's

Re: [HACKERS] A Windows x64 port of MySQL

--On Mittwoch, Juli 02, 2008 07:39:29 -0400 Ken Camann <[EMAIL PROTECTED]> wrote: I assume it would only really matter if you did this to a pointer, and perhaps that is happening somewhere (but I doubt it since postgres runs fine on 64-bit POSIX OSes). These would be easy to fix, but very ann

Re: [HACKERS] Please claim review items for commit fest!

"Dave Page" <[EMAIL PROTECTED]> writes: > On Wed, Jul 2, 2008 at 11:44 AM, Marko Kreen <[EMAIL PROTECTED]> wrote: > >> The comments should go to wiki? Not mailing list? > > It's a fine line (and slightly bendy line) - but simple comments can > go on the wiki, discussion should go to the list and

Re: [HACKERS] Fairly serious bug induced by latest guc enum changes

Tom Lane wrote: > Magnus Hagander <[EMAIL PROTECTED]> writes: >> Not having looked at md.c (I confess...) but don't we have a problem in >> case we have closed the file without fsyncing it, and then change the >> fsync parameter? > > Well, we don't promise to retroactively fsync stuff we didn't be

Re: [HACKERS] PATCH: CITEXT 2.0

David E. Wheeler napsal(a): On Jul 1, 2008, at 07:38, Tom Lane wrote: However, it will be solved when collation per column will be implemented. Well, yeah, but that seems a very long way off. In the meantime a lot of people use the existing pgfoundry citext module. And even more of us have

Re: [HACKERS] A Windows x64 port of PostgreSQL

Ken Camann napsal(a): Hello everyone, I don't really know much about contributing to projects, mailing lists, or really anything that has to do with the UNIX culture (I am not a UNIX fan). So forgive my ignorance of how this is supposed to work. I think you meant PostgreSQL not MySQL in the s

[HACKERS] pg_compresslog/pg_decompresslog

I found the discussion about log compressing here: http://archives.postgresql.org/pgsql-patches/2007-03/msg00502.php But I cannot find the scripts (pg_compresslog/pg_decompresslog), how can I get those? Will this work for 8.1 branch too? I want to use PITR, but archiving over one days will gener

[HACKERS] A Windows x64 port of MySQL

Hello everyone, I don't really know much about contributing to projects, mailing lists, or really anything that has to do with the UNIX culture (I am not a UNIX fan). So forgive my ignorance of how this is supposed to work. Basically I am trying to compile postgres as a native x64 application.

Re: [HACKERS] [patch] plproxy v2

I took the libery and changed the status from WIP to Pending Review, because the pending cleanups do not affect reviewing nor committing. And anyway, because of the patch size I expect reviewers requesting furthers changes so I'd like to push the tiny stuff to final version of the patch. -- mark

Re: [HACKERS] Please claim review items for commit fest!

On Wed, Jul 2, 2008 at 11:44 AM, Marko Kreen <[EMAIL PROTECTED]> wrote: > On 7/2/08, Dave Page <[EMAIL PROTECTED]> wrote: >> On Wed, Jul 2, 2008 at 11:37 AM, Marko Kreen <[EMAIL PROTECTED]> wrote: >> > I don't understand one aspect - if I'm unfamiliar with Postgres >> > and cannot do full review

Re: [HACKERS] Please claim review items for commit fest!

On 7/2/08, Dave Page <[EMAIL PROTECTED]> wrote: > On Wed, Jul 2, 2008 at 11:37 AM, Marko Kreen <[EMAIL PROTECTED]> wrote: > > I don't understand one aspect - if I'm unfamiliar with Postgres > > and cannot do full review or am familiar but cannot do full > > review due to time aspects but still w

Re: [HACKERS] Please claim review items for commit fest!

On Wed, Jul 2, 2008 at 11:37 AM, Marko Kreen <[EMAIL PROTECTED]> wrote: > I don't understand one aspect - if I'm unfamiliar with Postgres > and cannot do full review or am familiar but cannot do full > review due to time aspects but still want to throw some quick > comments, should I register on w

Re: [HACKERS] Please claim review items for commit fest!

On 7/2/08, Josh Berkus <[EMAIL PROTECTED]> wrote: > Just in case anyone was unclear, this is how we're trying things for > this commitfest: > > 1) Starting RIGHT NOW, reviewers should claim review items they are > interested in or specially qualified to review. > > 2) This weekend, I will chec

Re: [HACKERS] Commitfest status?

Zdenek Kotala napsal(a): Tom Lane napsal(a): Well, it's July 1, and time for another commit fest to begin. Do we have all the submitted patches queued up at http://wiki.postgresql.org/wiki/CommitFest:2008-07 ? There is Collation at database level patch. http://archives.postgresql.org/pgsql-hac

Re: [HACKERS] Commitfest status?

Tom Lane napsal(a): Well, it's July 1, and time for another commit fest to begin. Do we have all the submitted patches queued up at http://wiki.postgresql.org/wiki/CommitFest:2008-07 ? There is Collation at database level patch. http://archives.postgresql.org/pgsql-hackers/2008-07/msg00019.php

Re: [HACKERS] Limits of backwards compatibility for psql's \d commands

At 2008-07-02 09:16:30 +0200, [EMAIL PROTECTED] wrote: > > I don't think we should add support for pre-7.4 releases. I agree. It's not worth the effort. -- ams -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/m

Re: [HACKERS] Limits of backwards compatibility for psql's \d commands

Tom Lane a écrit : I'm fooling around with Guillaume Lelarge's patch to make psql's \d commands work with older server versions. The patch as submitted works with servers back to 7.4 (modulo a small bug or two). I tried to see what it'd take to make it work with 7.3. I count about a dozen triv