On Mon, Aug 15, 2005 at 11:30:32PM +0200, Andreas Seltenreich wrote:
>
> This would be one possibility. If you don't want your application to
> deal with transactions being aborted because of non-serializable
> transactions, you could alternatively use explicit locking (SELECT ...
> FOR UPDATE) co
Bill Moseley schrob:
> On Sat, Aug 13, 2005 at 06:44:09PM +0200, Andreas Seltenreich wrote:
>> > 3) Oh, and I have also this for checking IF there are items in
>> > "region" that are "above" the item in question -- to see IF an item
>> > can or cannot be moved up in the sort order relative to othe
On Sat, Aug 13, 2005 at 06:44:09PM +0200, Andreas Seltenreich wrote:
> > 3) Oh, and I have also this for checking IF there are items in
> > "region" that are "above" the item in question -- to see IF an item
> > can or cannot be moved up in the sort order relative to others.
> >
> > SELECT id F
Bill Moseley schrob:
> create table region {
> id SERIAL PRIMARY KEY,
> nametext,
> -- order this table should be sorted in
> -- a "1" is the top sort level
> sort_order integer
> );
>
> create table city {
> id SERIAL PRIMARY KEY,
> nametext,
I have a few beginner questions about using related tables for
sorting.
create table region {
id SERIAL PRIMARY KEY,
nametext,
-- order this table should be sorted in
-- a "1" is the top sort level
sort_order integer
);
create table city {
id SERIAL
