Re: [GENERAL] Multi row sequence?

2004-12-18 Thread Michael Fuhr
On Fri, Dec 17, 2004 at 11:10:12AM -, Filip Wuytack wrote: > Is it possible to have a sequence (as a multirow prim key), where sequence > (id) only increase per group of data (grp). > > E.g. > +++-+ > | grp| id | name| > +++-+ > | fish | 1 |

Re: [GENERAL] UNION with more restrictive DISTINCT

2004-12-18 Thread Vincent Hikida
One solution is SELECT COALESCE(t1.id,t2.id) , COALESCE(t1.name,t2.name) FROM t1 FULL JOIN t2 ON t1.id = t2.id - Original Message - From: "peter pilsl" <[EMAIL PROTECTED]> To: "PostgreSQL List" <[EMAIL PROTECTED]> Sent: Wednesday, December 15, 2004 1:03 PM Subject: [GENERA

Re: [GENERAL] NewsForge Poll: Favorite open source database?

2004-12-18 Thread Oleg Bartunov
On Thu, 16 Dec 2004, Marcelo Cid wrote: http://www.newsforge.com/pollBooth.pl?qid=54 I see strange line below results: "(You've already voted.)" I don't believe such results because I do know I didn't been here :) §ion=mainpage&aid=4

[GENERAL] could not read block 84253 of relation "tablename": Input/output error

2004-12-18 Thread ruben
Hi: No way to access "tablename". Can I do something to recover? Is this a hardware error? PostgreSQL 7.4.5 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) Thanks in advance. Ruben. ---(end of broadcast)---

Re: [GENERAL] NewsForge Poll: Favorite open source database?

2004-12-18 Thread Mike Mascari
Oleg Bartunov wrote: On Thu, 16 Dec 2004, Marcelo Cid wrote: http://www.newsforge.com/pollBooth.pl?qid=54 I see strange line below results: "(You've already voted.)" I don't believe such results because I do know I didn't been here :) Marcel's link did the favor of voting for you. Not good Mi

Re: [GENERAL] BTree max row size?

2004-12-18 Thread Alvaro Herrera
On Thu, Dec 16, 2004 at 06:20:57PM -0500, Ernest Kim wrote: Hi, > I'm getting the following error message when I try to update a row in > a table: > > ERROR: 54000: index row size 2720 exceeds btree maximum, 2713 > > Does anyone know how to to change the btree maximum row size? How did > it c

Re: [GENERAL] OSX 10.3.7 broke Postgresql 8.0.0b5?

2004-12-18 Thread Timothy Perrigo
On Dec 17, 2004, at 11:10 PM, Tom Lane wrote: Fascinating. As far as I can tell on my machine, 10.3.7 did not change the kernel IPC limits. So if it's not working for you guys that would suggest that 10.3.7 added some new background usage of IPC resources, which in combination with the PG postmas

Re: [GENERAL] Multi row sequence?

2004-12-18 Thread Bruno Wolff III
On Fri, Dec 17, 2004 at 11:10:12 -, Filip Wuytack <[EMAIL PROTECTED]> wrote: > Hi, > > I just started looking into PostgreSQL (coming from Mysql before), but have > a question: > > Is it possible to have a sequence (as a multirow prim key), where sequence > (id) only increase per group of d

Re: [GENERAL] OSX 10.3.7 broke Postgresql 8.0.0b5?

2004-12-18 Thread Scott Ribe
> It looks like yours has 100/1000 --- did you hand-modify that? Or maybe > you hand-modified the kernel limits? Another possible explanation is > that the 10.3.7 update overwrote any local changes you'd made to the IPC > limits. All the recent OS X .x updates have replaced /etc/rc. For all I kn

Re: [GENERAL] Multi row sequence?

2004-12-18 Thread Bruno Wolff III
On Sat, Dec 18, 2004 at 17:19:27 -, Filip Wuytack <[EMAIL PROTECTED]> wrote: > I'm working on a database that will contain companies (group) and the > relevant listing (securities-> id) and related periodic information. I want > the end users of the data to see the relationship between the 2

[GENERAL] Make a query faster...

2004-12-18 Thread v . demartino2
Dear all, Context: FreeBSD postgresql 7.4.5, on a pentium 3 server 128MB. I have a huge table letture02 made of 1,340,000 "freezed" records of 98 columns each (they do not change over time because the data are related to measurements made in 2002 and 2003 there is no need to update them or, worst

Re: [GENERAL] OSX 10.3.7 broke Postgresql 8.0.0b5?

2004-12-18 Thread Tom Lane
Scott Ribe <[EMAIL PROTECTED]> writes: >> It looks like yours has 100/1000 --- did you hand-modify that? Or maybe >> you hand-modified the kernel limits? Another possible explanation is >> that the 10.3.7 update overwrote any local changes you'd made to the IPC >> limits. > All the recent OS X .

Re: [GENERAL] Scheduler in Postgres

2004-12-18 Thread Jim C. Nasby
As I mentioned before, I think most (if not all) of the development effort would be outside the core database, meaning any of us would be able to work on it (as opposed to internal stuff which requires a lot more knowledge). There are two features dbms_job has that would probably require some inter

Re: [GENERAL] Scheduler in Postgres

2004-12-18 Thread Jim C. Nasby
Can you open-source your code? I'm sure others would benefit from it. On Thu, Dec 16, 2004 at 09:37:04AM -0800, Steve Atkins wrote: > On Thu, Dec 16, 2004 at 10:12:46AM +0100, Marco Colombo wrote: > > On Wed, 15 Dec 2004, Jim C. Nasby wrote: > > > > >No, PostgreSQL doesn't have an equivalent to O

Re: [GENERAL] Best practice in postgres

2004-12-18 Thread Jim C. Nasby
On Sat, Dec 11, 2004 at 10:40:42PM -0600, Guy Rouillier wrote: > Nilesh Doshi wrote: > > Also, I thought vacuuming will be easier if oracle schema becomes > > database in postgres. For example in our case each schema is like > > 80-90 gb, smaller compare to vacuuming on 400gb. > > I'm very new to

Re: [GENERAL] Scheduler in Postgres

2004-12-18 Thread Jim C. Nasby
On Fri, Dec 17, 2004 at 12:07:21PM -0500, Greg Stark wrote: > > Csaba Nagy <[EMAIL PROTECTED]> writes: > > > Now, cron isn't exactly part of the OS, is it ? > > Yes, it is. Depends on how you define 'OS'. Linux is nothing but a kernel afterall, so it's up to each distro to decide if they'll inc

Re: [GENERAL] Scheduler in Postgres

2004-12-18 Thread Jim C. Nasby
On Fri, Dec 17, 2004 at 03:25:20PM -0800, Ben wrote: > I have many such tasks. Depending on implementation, it has the potential > to be a TINY amount of less work to schedule such tasks from inside > the database, but it takes all of about a minute to schedule it through > cron. Including the amou

pgpool registered on pgfoundry (Re: [GENERAL] gborg.postgresql.org)

2004-12-18 Thread Tatsuo Ishii
Thanks. I have succesfully registered pgpool project on pgfoundry.org(http://pgfoundry.org/projects/pgpool/). I have been working on the site, and have just set up a mailing list, web page, and uploaded latest version of pgpool tar ball. -- Tatsuo Ishii > > It seems gborg does not accept new proj

Re: [GENERAL] Scheduler in Postgres

2004-12-18 Thread Steve Atkins
On Sat, Dec 18, 2004 at 03:01:54PM -0600, Jim C. Nasby wrote: > Can you open-source your code? I'm sure others would benefit from it. Eh. Big chunks of it are application specific, and a fair bit of the rest uses some commercial libraries. I'll see what I can do. (It'd be worth it to kill the mont

Re: [GENERAL] Scheduler in Postgres

2004-12-18 Thread Christopher Browne
Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] ("Jim C. Nasby") would write: > In PostgreSQL, there's currently no way to assume the identity of > another user. I'm confused at that... There seem to be ways at time of connection establishment, whether via the psql "-U" option, or the

Re: [GENERAL] Scheduler in Postgres

2004-12-18 Thread Tom Lane
Christopher Browne <[EMAIL PROTECTED]> writes: > Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] ("Jim C. Nasby") > would write: >> In PostgreSQL, there's currently no way to assume the identity of >> another user. > I'm confused at that... > There seem to be ways at time of connection

Re: [GENERAL] Scheduler in Postgres

2004-12-18 Thread Christopher Browne
I'm confused at that... There seem to be ways at time of connection establishment, whether via the psql "-U" option, or the PGconnect "dbuser=foo" option, or during a psql session via "\c - newuser" In what way do those not represent "assumption of a user's identity"? -- wm(X,Y):-write(X),write(

Re: [GENERAL] Get diagnistic (row_count) 7.3 vs. 7.4 changes

2004-12-18 Thread Bruce Momjian
Because the GET DIAGNOSTICS is after the CREATE TEMP TABLE command, I think zero is the right value, rather than the number of rows in the SELECT. I can see why it was handy to do it the old way in 7.3 but it seems it was a byproduct of GET DIAGNOSTICS not working properly. I suppose the only cl