Not sure it the title of this post gives a clear message...I need to have a
trigger function insert records into a table under certain conditions, where
the values inserted are partially based on the results of a select query.
table t_item
item_id (pk)
item_name
item_org_id
item_active
So what happens in those cases where the primary node gets in trouble
but isn't actually dead yet?
Hmmm. Is this really a problem? Couldn't the secondary DRBD node simply
stop accepting replicated data from the primary node before firing up
postmaster? Then the postmaster on the primary DRBD
On Sun, May 20, 2007 at 12:01:46PM +0200, Thomas Lopatic wrote:
Hmmm. Is this really a problem? Couldn't the secondary DRBD node simply
stop accepting replicated data from the primary node before firing up
postmaster? Then the postmaster on the primary DRBD node would only
write locally and
hi group :)
How do use hex numbers in psql? I.E.
instead of:
select 16
I want to do
select 0x10
like in c++
I tried doing what this website said
http://www.faqs.org/docs/ppbook/c12119.htm
but it does not work
TY :)
---(end of
sry, one more question ...
I want to trap an exception and return a -1 no matter WHAT it is ... what do
i need to replace anything with?
create or replace function clrsplit(int4) returns unknown as
$$
BEGIN
delete from split where tkid=$1;
EXCEPTION
WHEN anything
return -1;
update tk set
On May 20, 2007, at 3:01 AM, Thomas Lopatic wrote:
So what happens in those cases where the primary node gets in trouble
but isn't actually dead yet?
Hmmm. Is this really a problem?
The problem comes when the primary is cannot replicate to the
secondary but can, for whatever reason, still
Thomas Lopatic wrote:
So what happens in those cases where the primary node gets in trouble
but isn't actually dead yet?
Hmmm. Is this really a problem? Couldn't the secondary DRBD node simply
stop accepting replicated data from the primary node before firing up
postmaster? Then the
Ben wrote:
On May 20, 2007, at 3:01 AM, Thomas Lopatic wrote:
The problem comes when the primary is cannot replicate to the secondary
but can, for whatever reason, still talk to clients. If a client is told
something is committed but that commit isn't replicated, you have a
problem.
Right,
- dblink would allow you to open another connection concurrently
This suggestion worked perfectly, thank you very much.
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail
On Sun, 20 May 2007, madhtr wrote:
How do use hex numbers in psql? I.E.
instead of:
select 16
I want to do
select 0x10
See 4.1.2.3: SELECT x'1FF'::int
http://www.postgresql.org/docs/8.2/static/sql-syntax-lexical.html#SQL-SYNTAX-CONSTANTS
Kris Jurka
---(end
madhtr [EMAIL PROTECTED] writes:
I want to trap an exception and return a -1 no matter WHAT it is ... what do
i need to replace anything with?
OTHERS
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched
So, I may have hammered out the basic trigger function. The error trapping
part is a complete mystery to me. I'll post the trigger function below in
the hopes that someone will at least comment on the error handling part.
The error, as expected is 'duplicate key violates unique contraint blah
Inching closer; the following handles the dupe key error but doesn't insert
the rows it should either. So, the exception is ending the insert, and not
continuing to insert for rows that don't violate the unique key restraint.
Is there a way around this or will I need to take a different approach?
Andrus [EMAIL PROTECTED] writes:
I've yet to see a real-world case where a
non-merge-joinable full-join condition was really needed.
I need to eliminate rows containing null value in left side table in full
join.
create table iandmed ( ametikoht integer );
insert into iandmed values(1);
novnov escribió:
Inching closer; the following handles the dupe key error but doesn't insert
the rows it should either. So, the exception is ending the insert, and not
continuing to insert for rows that don't violate the unique key restraint.
Is there a way around this or will I need to take
It's an after trigger.
Any clue re my question?
Alvaro Herrera-7 wrote:
novnov escribió:
Inching closer; the following handles the dupe key error but doesn't
insert
the rows it should either. So, the exception is ending the insert, and
not
continuing to insert for rows that don't
novnov [EMAIL PROTECTED] writes:
Any clue re my question?
You've placed the INSERT inside the BEGIN/EXCEPTION block, ergo it's
part of the work to be rolled back on exception.
regards, tom lane
---(end of broadcast)---
TIP
I understand that this has been discussed before, but I was hoping
that somebody might have some fresh ideas on the problem.
I'm using Postgres for my web app, I users that interface with the
database through the app. All records are classified with an industry
and an occupation. Currently
OK, but, how do I set this up to do what I need? I want an insert that would
create a dupe key to be rolled back, and inserts that would not create dupe
keys to be committed.
Tom Lane-2 wrote:
novnov [EMAIL PROTECTED] writes:
Any clue re my question?
You've placed the INSERT inside the
19 matches
Mail list logo
