pg.ddx.io pgsql-sql@postgresql.org mailing list archive
help / color / mirror / Atom feedBitfields always atomic? Other way to store attributes?
5+ messages / 5 participants
[nested] [flat]
* Bitfields always atomic? Other way to store attributes?
@ 2006-03-26 21:47 Bryce Nesbitt <bryce1@obviously.com>
2006-03-27 19:13 ` Re: Bitfields always atomic? Other way to store attributes? Peter Eisentraut <peter_e@gmx.net>
2006-03-27 19:20 ` Re: Bitfields always atomic? Other way to store attributes? Janning Vygen <vygen@gmx.de>
0 siblings, 2 replies; 5+ messages in thread
From: Bryce Nesbitt @ 2006-03-26 21:47 UTC (permalink / raw)
To: pgsql-sql
Dear List;
If I have two threads modifying the same "bit" field:
thread1=> update table set bf=bf | '01000'
thread2=> update table set bf=bf | '10000'
Will this operation always be safe (e.g. result in bf='11000')? Or must
I wrap things in
explicit transactions?
My application is to give attributes to an address table. But maybe
there is a better way?
I want to mark each addresses with attributes, e.g. the person may be a
"friend", "on my holiday card list", "owe me money", be an "employee", a
"volunteer on the xxx project", or none of the above.
I could assign each role a bit.
Or, create a string field: "Friend,Money, Emp,VolXXX".
Or, create related tables:
friend_pk, address_id
cardlist_pk, address_id
money_pk, address_id, amount_owed
volunteer_pk, address_id
Any thoughts?
-Bryce Nesbitt
--
----
Visit http://www.obviously.com/
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Bitfields always atomic? Other way to store attributes?
2006-03-26 21:47 Bitfields always atomic? Other way to store attributes? Bryce Nesbitt <bryce1@obviously.com>
@ 2006-03-27 19:13 ` Peter Eisentraut <peter_e@gmx.net>
1 sibling, 0 replies; 5+ messages in thread
From: Peter Eisentraut @ 2006-03-27 19:13 UTC (permalink / raw)
To: pgsql-sql; +Cc: Bryce Nesbitt <bryce1@obviously.com>
Bryce Nesbitt wrote:
> If I have two threads modifying the same "bit" field:
> thread1=> update table set bf=bf | '01000'
> thread2=> update table set bf=bf | '10000'
> Will this operation always be safe (e.g. result in bf='11000')? Or
> must I wrap things in
> explicit transactions?
Each of these commands will be its own transaction if you don't
explicitly start one.
> My application is to give attributes to an address table. But maybe
> there is a better way?
Create 5 boolean fields.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Bitfields always atomic? Other way to store attributes?
2006-03-26 21:47 Bitfields always atomic? Other way to store attributes? Bryce Nesbitt <bryce1@obviously.com>
@ 2006-03-27 19:20 ` Janning Vygen <vygen@gmx.de>
1 sibling, 0 replies; 5+ messages in thread
From: Janning Vygen @ 2006-03-27 19:20 UTC (permalink / raw)
To: pgsql-sql; +Cc: Bryce Nesbitt <bryce1@obviously.com>
Am Sonntag, 26. März 2006 23:47 schrieb Bryce Nesbitt:
> Dear List;
>
> If I have two threads modifying the same "bit" field:
> thread1=> update table set bf=bf | '01000'
> thread2=> update table set bf=bf | '10000'
> Will this operation always be safe (e.g. result in bf='11000')?
yes, Thats what "ACID" (http://en.wikipedia.org/wiki/ACID) is all about.
> Or must
> I wrap things in
> explicit transactions?
every statement is in it's own transaction as long as you dont start one by
yourself.
> My application is to give attributes to an address table. But maybe
> there is a better way?
>
> I want to mark each addresses with attributes, e.g. the person may be a
> "friend", "on my holiday card list", "owe me money", be an "employee", a
> "volunteer on the xxx project", or none of the above.
>
> I could assign each role a bit.
>
> Or, create a string field: "Friend,Money, Emp,VolXXX".
>
> Or, create related tables:
> friend_pk, address_id
> cardlist_pk, address_id
> money_pk, address_id, amount_owed
> volunteer_pk, address_id
>
> Any thoughts?
create a table with attributes and a table with addresse "address" and then
link them via a third table address_addressattributes, something like this:
create table address (
add_id serial not null primary key,
add_name text not null,
add_street ...
...
);
create table addressattributes (
aa_id serial not null primary key,
aa_name text not null unique
);
insert into address_attributes (aa_name) values ('Friend');
insert into address_attributes (aa_name) values ('Money');
create table address_addressattributes (
add_aa_id serial primary key,
aa_id int4 not null references address_attributes (aa_id),
add_id int4 not null references address (add_id)
)
this is called a many-to-many relation.
kind regards,
janning
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Bitfields always atomic? Other way to store attributes?
@ 2006-03-28 21:55 TJ O'Donnell <tjo@acm.org>
0 siblings, 0 replies; 5+ messages in thread
From: TJ O'Donnell @ 2006-03-28 21:55 UTC (permalink / raw)
To: pgsql-sql; +Cc: bryce1@obviously.com
> If I have two threads modifying the same "bit" field:
> thread1=> update table set bf=bf | '01000'
> thread2=> update table set bf=bf | '10000'
> Will this operation always be safe (e.g. result in bf='11000')? Or
Won't this always result in bf='11xxx', depending on the
original values of bf?
TJ
www.gnova.com
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Bitfields always atomic? Other way to store attributes?
@ 2006-03-28 21:59 Owen Jacobson <ojacobson@osl.com>
0 siblings, 0 replies; 5+ messages in thread
From: Owen Jacobson @ 2006-03-28 21:59 UTC (permalink / raw)
To: pgsql-sql
TJ O'Donnell wrote:
> > If I have two threads modifying the same "bit" field:
> > thread1=> update table set bf=bf | '01000'
> > thread2=> update table set bf=bf | '10000'
> > Will this operation always be safe (e.g. result in bf='11000')? Or
>
> Won't this always result in bf='11xxx', depending on the
> original values of bf?
Not even. Consider:
thread1=> update table set bf=bf | '01000'
thread3=> update table set bf=bf & '10111'
thread2=> update table set bf=bf | '10000'
Now you get bf=10xxx.
They're thread safe in that all transformations will be applied as-if serially, so no bit sets or unsets will be lost, but you can't guarantee that another client won't interfere with the results.
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2006-03-28 21:59 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-03-26 21:47 Bitfields always atomic? Other way to store attributes? Bryce Nesbitt <bryce1@obviously.com>
2006-03-27 19:13 ` Peter Eisentraut <peter_e@gmx.net>
2006-03-27 19:20 ` Janning Vygen <vygen@gmx.de>
2006-03-28 21:55 Re: Bitfields always atomic? Other way to store attributes? TJ O'Donnell <tjo@acm.org>
2006-03-28 21:59 Re: Bitfields always atomic? Other way to store attributes? Owen Jacobson <ojacobson@osl.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox