[GENERAL] Passing refcursors between pl/pgsql functions

, but can it? END $$ language plpgsql; Is it possible to do such a thing? I have a feeling that it isn't, but I'd love to be proven wrong. Thanks in advance, Reuven -- Reuven M. Lerner -- Web development, consulting, and training Mobile: +972-54-496-8405 * US phone: 847-230-9795 Skype/A

Re: [GENERAL] Passing refcursors between pl/pgsql functions

pen), and should return a set of rows from the table on which it was opened. This isn't the way that I would want to do things, but my client's application structure seems to require it, at least for now. So, is there a way to do this? Reuven -- Reuven M. Lerner -- Web development,

Re: [GENERAL] Passing refcursors between pl/pgsql functions

Hi, Merlin. Thanks for the clarification and explanation; it was quite helpful. I'll give it a shot! Reuven -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Getting ROW_COUNT from MOVE in 8.3

ows over which a cursor has skipped? Keep in mind that after this count has executed, we're then going to rewind the cursor, chunking through the result set with a separate function. Thanks in advance, Reuven -- Reuven M. Lerner -- Web development, consulting, and training Mobile: +

Re: [GENERAL] Getting ROW_COUNT from MOVE in 8.3

a bad way to go, given the lack of information. That said, I'm sort of surprised that the psql client is able to show us the number of rows through which MOVE operated, while we're unable to access that number in pl/pgsql. But hey, that's yet another welcome addition to 9.0..

[GENERAL] Hanging with pg_restore and large objects

ch as text, to get around this problem for now? * Is there any obvious way to diagnose or work around this problem? * I don't believe that there's a way to tell either pg_dump or pg_restore to ignore objects with particular OIDs. Am I right? Thanks in advance for any

Re: [GENERAL] Hanging with pg_restore and large objects

, but we can't switch it into widespread use right now. (We have 8.3 installed in a closed-box product that's physically distributed to customers.) We can mix and match 8.3 and 9.0 in the development lab, but not on a widespread scale. Reuven -- Reuven M. Lerner -- Web developm

Re: [GENERAL] Hanging with pg_restore and large objects

e data sufficiently non-proprietary that you'd be willing to show the dump file to someone else? I'm guessing that if we have dummy data in there, then we can share it. I'll get back to you about this in the coming day or two. Thanks for the offer! Reuven -- Reuven M. Lerner -- We

[GENERAL] Questions about octal vs. hex for bytea

k with people here, just to double-check my understanding. Thanks in advance, Reuven -- Reuven M. Lerner -- Web development, consulting, and training Mobile: +972-54-496-8405 * US phone: 847-230-9795 Skype/AIM: reuvenlerner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) T

Re: [GENERAL] Questions about octal vs. hex for bytea

Thanks, everyone, for the swift and clear responses. It's good to know that I did understand things correctly! Reuven -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Pending trigger events on ALTER TABLE in 8.3

;'; EXECUTE 'ALTER TABLE "' || table_name || '" DROP COLUMN "' || column_name || '" '; EXECUTE 'ALTER TABLE "' || table_name || '" RENAME COLUMN "' || new_column_name || '" TO "' || column

Re: [GENERAL] Pending trigger events on ALTER TABLE in 8.3

ll Description | text | IsOptional | boolean| not null Direction | integer| not null HostExposed | boolean| not null default true Indexes: "Parameter_pkey" PRIMARY KEY, btree ("Name", "RecipeID"

Re: [GENERAL] Pending trigger events on ALTER TABLE in 8.3

that some foreign key is being referenced or handled earlier in the transaction. I'll look in that direction; thanks! Reuven -- Reuven M. Lerner -- Web development, consulting, and training Mobile: +972-54-496-8405 * US phone: 847-230-9795 Skype/AIM: reuvenlerner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Pending trigger events on ALTER TABLE in 8.3

Thanks for the great explanation! Now it's time to do some detective work... Reuven -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Failover architecture

ssed something obvious in the documentation, then a pointer to the appropriate resource would be more than welcome.n Reuven -- Reuven M. Lerner -- Web development, consulting, and training Mobile: +972-54-496-8405 * US phone: 847-230-9795 Skype/AIM: reuvenlerner

Re: [GENERAL] Failover architecture

Thanks, Tatsuo, and others who commented so helpfully.  It's the best of all worlds when I get confirmation that my feelings were right, *and* I learn a lot of new things that I had never considered, thanks to the generosity of this great community. Reuven

[GENERAL] Speed of lo_unlink vs. DELETE on BYTEA

cts, and then find a way other than a rule to deal with deleting them on this sort of scale?  Or (of course) am I missing another good option? Thanks for any and all advice, as usual! Reuven -- Reuven M. Lerner -- Web development, consulting, and training Mobile: +9

Re: [GENERAL] Speed of lo_unlink vs. DELETE on BYTEA

Hi again, everyone.  I'm replying to my own posting, to add some information: I decided to do some of my own benchmarking.  And if my benchmarks are at all accurate, then I'm left wondering why people use large objects at all, given their clunky API and their extremely sl

Re: [GENERAL] Speed of lo_unlink vs. DELETE on BYTEA

| 1m48.369s | Ideas, anyone? Reuven -- Reuven M. Lerner -- Web development, consulting, and training Mobile: +972-54-496-8405 * US phone: 847-230-9795 Skype/AIM: reuvenlerner

Re: [GENERAL] Speed of lo_unlink vs. DELETE on BYTEA

however, is still much faster with bytea than large objects. I've put my benchmark code up on GitHub for people to run and play with, to see if they can reproduce my results: https://github.com/reuven/pg-delete-benchmarks Reuven -- Re

[GENERAL] Searching for "bare" letters

racter for search purposes, or if I need to do something else -- use regexps, keep a "naked," searchable version of each column alongside the native one, or something else entirely -- to get this to work. Any ideas? Thanks, Reuven -- Reuven M. Lerner

Re: [GENERAL] Searching for "bare" letters

ggestions. Reuven -- Reuven M. Lerner -- Web development, consulting, and training Mobile: +972-54-496-8405 * US phone: 847-230-9795 Skype/AIM: reuvenlerner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Searching for "bare" letters

ectly. I'll take a look; thanks for the suggestion. Reuven -- Reuven M. Lerner -- Web development, consulting, and training Mobile: +972-54-496-8405 * US phone: 847-230-9795 Skype/AIM: reuvenlerner -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make chan

[GENERAL] Database slowness -- my design, hardware, or both?

Hi, everyone. I've been using PostgreSQL for a decade, and it hasn't failed me yet. But I've been having some serious performance problems on a database that I've been using in my grad-school research group, and it's clear that I need help from some more experienced hands. Basically, we've c

[GENERAL] (no subject)

---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly

Re: [GENERAL] Database slowness -- my design, hardware, or both?

Hi, Tom. You wrote: Hi, everyone. I've been using PostgreSQL for a decade, and it hasn't failed me yet. But I've been having some serious performance problems on a database that I've been using in my grad-school research group, and it's clear that I need help from some more experienced hands

Re: [GENERAL] Database slowness -- my design, hardware, or both?

Hi, Webb Sprague. You wrote: How much concurrency is there on your database? Almost none. I'm generally running one client against the server. I often have a second client connected simultaneously, just for the purpose of answering short questions. I'm now thinking of separating each activ

Re: [GENERAL] Database slowness -- my design, hardware, or both?

Hi, Webb Sprague. You wrote: ... but I see two seq scans in your explain in a loop -- this is probably not good. If you can find a way to rewrite the IN clause (either de-normalizing through triggers to save whatever you need on an insert and not have to deal with a set, or by using except in t

Re: [GENERAL] Database slowness -- my design, hardware, or both?

Hi, Alvaro Herrera. You wrote: Don't assume -- measure. I had a query which ran orders of magnitude faster because I interpolated the constant list in the big query. The table from which the interpolated values were being extracted had about 30 rows or so. OK, I modified things to use inte

Re: [GENERAL] Database slowness -- my design, hardware, or both?

Hi, Webb Sprague. You wrote: Do you have new \timings? Yup. It just finished executing a little while ago. With the explicitly interpolated array in place, I got the following: LOG: statement: UPDATE Transactions SET previous_value = previous_value(id) W

[GENERAL] Recovering a messed-up database

I'm running a PostgreSQL 8.2.0 system on RHEL WS (update 5). The machine is administered by someone else. To make a long story short, I thought that the site administrator was making regular backups, and that I was running pg_dump every night. Unfortunately, neither assumption was quite righ

Re: [GENERAL] Many Pl/PgSQL parameters -> AllocSetAlloc(128)?

Excellent -- thanks so much for your help. I just tried the function with the right arguments, and it worked just fine. Yet more proof of named parameters being a good thing... Reuven ---(end of broadcast)--- TIP 7: don't forget to increase your f

[GENERAL] Better error messages from JDBC

Hi, folks. I've been using PostgreSQL over the last six months or so (after a bitter experience 2-3 years ago), and have been overwhelmingly pleased with what I see. Good job, all you core developers! My question is whether I can get better error messages from JDBC than the text of an SQLExcept