Hello,
this fails with "duplicate key value":
CREATE TABLE x (
i INT NOT NULL UNIQUE
);
INSERT INTO x (i) VALUES (1), (2), (3);
UPDATE x SET i = i + 1;
are there any plans to make this work?
--
Roman Neuhauser
--
Sent via pgsql-general mailing list (pgsql-general@postgr
Ragnar wrote:
Reguardless of the issue whether pl/pgsql could be expected to
optimize this case, I find it difficult to imagine a scenario
where this kind of coding makes sense.
I understand that in some cases on would like to do this with
a *variable* to simplify logic, but what possible gain c
Tom Lane wrote:
[EMAIL PROTECTED] writes:
I would submit that in that situation, it would be
reasonable for a user to expect my suggested syntax to still use the
indicated indexes.
The only thing that will make that work is if "indexed_col IS NULL" were
an indexable condition, which it isn't
[EMAIL PROTECTED] wrote:
Tom Lane wrote:
you're still gonna lose because those are variables not constants ...
Well, that *is* what I'm hoping to do. I understand how (0 IS NULL) is
different from (variable IS NULL), but isn't it reasonable to expect
that PG could evaluate that expression o
Thanks Chris,
I see you a core member of Slony team and a replication guru so I'll look
into it.
I'm not slamming Slony I think its probably the right tool for type of work
your company Afilias does. Just wish you would make an official Windows
version of Slony as well.
Anyway thanks for the ed
Tom Lane wrote:
Well, you could update --- 8.2 contains code to recognize that the IS
NULL expression is constant, but prior releases do not.
That's excellent to hear -- I'd missed that in my perusing of the
changelogs between 8.0.x and 8.2. That does give me one more reason to
upgrade. It
Thanks Bruce... just read it, still running 8.1 so didnt see 8.2
documentation.
Nice to know my work has not been duplicated... quote from
http://www.postgresql.org/docs/8.2/static/high-availability.html
"PostgreSQL does not offer this type of replication, though PostgreSQL
two-phase commit (PREP
>Hi,
>
>I am currently investigating the preferred method of clustering a postgresql
>database on Redhat?
>
>i would really appreciate some suggestions or experiences you guys have had.
>
>note: performance & redundancy are both equally desirable and i have plenty of
>resources.
>
>we already
Hello,
I've been using PostgreSQL for a few years and mostly love it. Aside
from a few (perceived, anyway) annoying limitations in PL/PGSQL (which I
almost exclusively am using for db interaction), I'm very satisfied with it.
I ran across this problem several months back and decided to blow
I've started using pgpool and while everything appears to be working,
I've been getting a lot of the following errors in my logs:
ERROR: pid 14761: pool_read: EOF encountered
This seems to be simple enough - the client/user probably just canceled
the request and isn't anything to be conc
10 matches
Mail list logo
