Re: [HACKERS] Numbering of the next release: 8.0 vs 7.4

2003-03-11 Thread Tom Lane
Justin Clift <[EMAIL PROTECTED]> writes: > Would it be cool to decide on the version numbering of our next release > like this: > + If it looks like we'll have Win32 and/or PITR recovery in time for > the next release, we call it PostgreSQL 8.0 > + If not, we call it 7.4 Works for me: rel

Re: [HACKERS] Roadmap for FE/BE protocol redesign

2003-03-11 Thread Tom Lane
Kevin Brown <[EMAIL PROTECTED]> writes: > doing more or less what other database vendors have done in response > to these underspecified issues is probably a sensible course of action > when there's no other obviously better answer. A good point, indeed. Who wants to do the legwork to check up on

Re: [HACKERS] Numbering of the next release: 8.0 vs 7.4

2003-03-11 Thread Justin Clift
Paul Ramsey wrote: Justin Clift wrote: Win32 and PITR are great big features that will take us a long way to the goal of Enterprise suitability. They're worth making some specific marketing/branding efforts about and making a big fuss, that why I'd like to see them in an 8.0 release. From a m

Re: [HACKERS] Numbering of the next release: 8.0 vs 7.4

2003-03-11 Thread Paul Ramsey
Justin Clift wrote: Win32 and PITR are great big features that will take us a long way to the goal of Enterprise suitability. They're worth making some specific marketing/branding efforts about and making a big fuss, that why I'd like to see them in an 8.0 release. From a marketing point of vi

[HACKERS] Numbering of the next release: 8.0 vs 7.4

2003-03-11 Thread Justin Clift
Hi everyone, Thinking about the numbering further. Would it be cool to decide on the version numbering of our next release like this: + If it looks like we'll have Win32 and/or PITR recovery in time for the next release, we call it PostgreSQL 8.0 + If not, we call it 7.4 Win32 and PITR ar

Re: [HACKERS] Roadmap for FE/BE protocol redesign

2003-03-11 Thread Bruce Momjian
Marc G. Fournier wrote: > > So, what should we do? Should we go another month or two and just wait > > until we have enough must-have features? While not waiting on specific > > features, it _is_ waiting for something to warrant a release. I guess > > the big question is whether we release on a

Re: [HACKERS] [INTERFACES] Roadmap for FE/BE protocol redesign

2003-03-11 Thread Marc G. Fournier
On Tue, 11 Mar 2003, Bruce Momjian wrote: > Marc G. Fournier wrote: > > On Mon, 10 Mar 2003, Tom Lane wrote: > > > > > One of the $64 questions that has to be answered is how much work we're > > > willing to expend on backwards compatibility. The path of least > > > resistance would be to handle

[HACKERS] specific questions regarding Oid and finding out the granularity of the lock

2003-03-11 Thread Sumaira Ali
what are the different types of lock modes available for row-level locks? I found a documentation on different types of lock modes available for table-level locks at http://developer.postgresql.org/docs/postgres/explicit-locking.html where is the documentation on different types of lock modes for

[HACKERS] how to get actual PGPROC and LOCK object from SHMEM_OFFSET???

2003-03-11 Thread Sumaira Ali
How do we get the actual pgproc object from the SHMEM_OFFSET proc /* link to pgproc of owning backend*/ in the PROCLOCKTAG struct in file Lock.h The same question also for SHMEM_OFFSET lock /*link to per-lockable-object information*/ in the same struct Is SHMEM_OFFSET a pointer to an address which

Re: [HACKERS] Roadmap for FE/BE protocol redesign

2003-03-11 Thread Marc G. Fournier
On Mon, 10 Mar 2003, Tom Lane wrote: > Justin Clift <[EMAIL PROTECTED]> writes: > > The scenario that's appealing to me the most is this for the next release: > > PostgreSQL 8.0 > > + Includes PITR and the Win32 port > > If the folks doing those things can get done in time, great. I'm even > will

Re: [HACKERS] [INTERFACES] Roadmap for FE/BE protocol redesign

2003-03-11 Thread Marc G. Fournier
On Mon, 10 Mar 2003, Tom Lane wrote: > One of the $64 questions that has to be answered is how much work we're > willing to expend on backwards compatibility. The path of least > resistance would be to handle it the same way we've done protocol > revisions in the past: the backend will be able to

[HACKERS] bitmask for lock types

2003-03-11 Thread Sumaira Ali
The way I understand it, grantMask in the LOCK struct (file Lock.h) could help us find out all the lock types already granted for an object associated with the LOCKTAG. How do we do the bit manipulation to 'separate' the mask to get to the different lock types associated with the object that acquir

[HACKERS] Request for quote

2003-03-11 Thread Dave Cramer
I have a customer porting an application from informix to postgres. They require 2 things: 1) Cursors outside of transactions. 2) For update cursors as well as where current of If anyone is interested in this work, please reply off list. -- Dave Cramer <[EMAIL PROTECTED]> Cramer Consulting -

Re: [HACKERS] Website build script

2003-03-11 Thread Alvaro Herrera
On Tue, Mar 11, 2003 at 10:40:08PM -, [EMAIL PROTECTED] wrote: > As far as the problem of generating an empty index file, you could have > the buildpage() function redirect the lynx output to a temporary file > ($1.temp) and check that file for validity somehow (i.e. non-zero size > or grep

Re: [HACKERS] Roadmap for FE/BE protocol redesign

2003-03-11 Thread Kevin Brown
Tom Lane wrote: > "Dave Page" <[EMAIL PROTECTED]> writes: > > Well, what would constitute a complete spec? I think I've told the group > > what I would like to be able to do, what unanswered questions can I > > (hopefully :-) ) answer? > > I'm still unclear on exactly what your needs are. In the

Re: [HACKERS] Largest filesize under Linux

2003-03-11 Thread Christopher Browne
After a long battle with technology,"Partho Bhowmick" <[EMAIL PROTECTED]>, an earthling, wrote: > Well, I am running kernel-2.4.18-26. What's the limit on this baby? Sounds like you didn't read what I wrote. Which filesystem? Which version of GLIBC? By the way, have your applications been comp

Re: [HACKERS] Website build script

2003-03-11 Thread Dave Page
> -Original Message- > From: Gavin Sherry [mailto:[EMAIL PROTECTED] > Sent: 11 March 2003 22:38 > To: Dave Page > Cc: [EMAIL PROTECTED] > Subject: Re: [HACKERS] Website build script > > > Seems possible that Lynx timed out and generated and sh left > only an empty file. > > Guard aga

Re: [HACKERS] Website build script

2003-03-11 Thread greg
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As far as the problem of generating an empty index file, you could have the buildpage() function redirect the lynx output to a temporary file ($1.temp) and check that file for validity somehow (i.e. non-zero size or grep for a known string ("Post

Re: [HACKERS] Website build script

2003-03-11 Thread Gavin Sherry
Seems possible that Lynx timed out and generated and sh left only an empty file. Guard against this by writing the output of lynx to a temporary file and either check it for stuff you expect to be there (?) or for some reasonable size. There are better was to do this, of course... Gavin ---

Re: [HACKERS] Largest filesize under Linux

2003-03-11 Thread Christopher Browne
Quoth "Partho Bhowmick" <[EMAIL PROTECTED]>: > I am working on extending the functionality of PostgreSQL on Linux. > I need to know what's the largest filesize for a single file that I can have > under Linux? That depends. It depends on the size supported by the filesystem. Usually that's at lea

Re: [HACKERS] gmake -C regress check failure

2003-03-11 Thread Christoph Haller
> > Christoph Haller <[EMAIL PROTECTED]> writes: > > I've installed postgresql-7.3.2 on HP-UX yesterday. > > When running 'gmake -C regress check' > > the process does not return. > > See doc/FAQ_HPUX: > > : The parallel regression test script (gmake check) is known to lock up > : when run under HP

Re: [HACKERS] gmake -C regress check failure

2003-03-11 Thread Tom Lane
Christoph Haller <[EMAIL PROTECTED]> writes: > I've installed postgresql-7.3.2 on HP-UX yesterday. > When running 'gmake -C regress check' > the process does not return. See doc/FAQ_HPUX: : The parallel regression test script (gmake check) is known to lock up : when run under HP's Bourne shells:

Re: [HACKERS] Roadmap for FE/BE protocol redesign

2003-03-11 Thread Andrew Dunstan
If there's a build of this available we'd love to test it in a major project we're working on. The project is currently using the 7.2 build that was made available, but we had to work around the lack of schema support by kludging table names as "namespace_table", so a 7.3 build would be great, wit

Re: [HACKERS] [INTERFACES] Roadmap for FE/BE protocol redesign

2003-03-11 Thread Tom Lane
"Magnus Hagander" <[EMAIL PROTECTED]> writes: > The general idea was to make a framework there to make it easier to add > something like that in the future. Something that came up when adding > the SSL negotiation - since that was very kludgy to do with the current > protocol. But again, if you for

Re: [HACKERS] Roadmap for FE/BE protocol redesign

2003-03-11 Thread Tom Lane
Hiroshi Inoue <[EMAIL PROTECTED]> writes: > What the driver has suffered from is to get the > fields' info of a query result or the parameters' > info of a statement. The info is needed even before > the execution of the statement(i.e it's only prepared). Hm. Are you saying that you would like PR

Re: [HACKERS] Roadmap for FE/BE protocol redesign

2003-03-11 Thread Bruce Momjian
Sure, Neil Conway updated Jan's patches for 7.3. It is in: ftp://candle.pha.pa.us/pub/postgresql/mypatches/ --- Merlin Moncure wrote: > Justin Clift wrote: > > confidentiality level of the Win32/PITR patches at pre

Re: [HACKERS] Roadmap for FE/BE protocol redesign

2003-03-11 Thread Merlin Moncure
Justin Clift wrote: > confidentiality level of the Win32/PITR patches at present, but I'd > guess there would be at least a few solid volunteers willing to > contribute to the Win32/PITR ports if we asked for people to step > forwards. I'd like to help. I've been following the list for several mo

Re: Beta schedule (was [HACKERS] Roadmap for FE/BE protocol redesign)

2003-03-11 Thread Bruce Momjian
I agree, let's not wait for specific features. The issue was whether we had enough significant features done for a release --- I didn't think we did, so I am saying, let's get more features, rather than let's get feature X. As we fill in missing features, there will be less must-have features to

Re: [HACKERS] Roadmap for FE/BE protocol redesign

2003-03-11 Thread Hiroshi Inoue
Tom Lane wrote: (B> (B> > I think such compatibility is sufficient. We can mention in the (B> > releases notes that they should upgrade there servers before their (B> > clients. (B> (B> I'd be really happy if we can make that stick. There's enough work to (B> be done here without trying

Re: [HACKERS] [INTERFACES] Roadmap for FE/BE protocol redesign

2003-03-11 Thread Magnus Hagander
> > X and Y? Well, the first thing that comes to mind is SSL > support. I'm > > not sure if it's still that way, but at least it used to be > a pretty > > ugly kludge there with the connection being dropped and > re-connected > > in some cases. > > SSL support is a bad example, since it woul

[HACKERS] gmake -C regress check failure

2003-03-11 Thread Christoph Haller
Maybe this is related to the thread [HACKERS] regression failure in CVS HEAD I've installed postgresql-7.3.2 on HP-UX yesterday. When running 'gmake -C regress check' the process does not return. File ./src/test/regress/regression.out shows parallel group (13 tests): float8 int2 varchar text

Re: [HACKERS] Roadmap for FE/BE protocol redesign

2003-03-11 Thread Dave Page
It's rumoured that Bruce Momjian once said: > Tom Lane wrote: >> Bruce Momjian <[EMAIL PROTECTED]> writes: >> > I was willing to add a hack to enable default column labels to be >> > "table.column" --- that seemed like the least obtrusive. >> >> Most of the definitional issues still apply: which ta

Re: [HACKERS] Roadmap for FE/BE protocol redesign

2003-03-11 Thread Dave Page
It's rumoured that Bruce Momjian once said: > Tom Lane wrote: >> "Dave Page" <[EMAIL PROTECTED]> writes: >> > What about the addition of pg_attribute.attrelid & >> > pg_attribute.attname/attnum in RowDesription messages to identify >> > the underlying attribute (where appropriate)? >> >> Well, we c

Re: [HACKERS] Roadmap for FE/BE protocol redesign

2003-03-11 Thread Dave Page
It's rumoured that Tom Lane once said: > "Dave Page" <[EMAIL PROTECTED]> writes: >> What about the addition of pg_attribute.attrelid & >> pg_attribute.attname/attnum in RowDesription messages to identify the >> underlying attribute (where appropriate)? > > Well, we can talk about it, but I still th