pg.ddx.io pgsql-general@postgresql.org mailing list archive
help / color / mirror / Atom feedOrder of Update
15+ messages / 5 participants
[nested] [flat]
* Order of Update
@ 2006-03-18 14:16 Terry Lee Tucker <terry@esc1.com>
0 siblings, 1 reply; 15+ messages in thread
From: Terry Lee Tucker @ 2006-03-18 14:16 UTC (permalink / raw)
To: pgsql-general
Hello List:
I'm having an "interesting" problem. I know what is happening, but I do not
know why; therefore, I am hoping that some of those very familiar with the
internals can/will explain it to me.
I have a function A written in plpgsql which is designed to undo changes to
several records. This function is called from an X Windows interface when the
user presses the "undo" button. The functions updates one or records in a
table within loop and then updates a "parent" record from a different table.
The updates in the loop depend on certain values being present in the
"parent" record. At the end of the loop, an update to the "parent" record
sets to NULL the values that were used in the loop updates. The problem is
that the update to the parent occurs first even though the code performing
the update is physically located below the loop. Here is the function:
CREATE OR REPLACE FUNCTION removeCash (INTEGER) RETURNS VOID AS '
DECLARE
cash_recid ALIAS FOR $1; -- recid of receipt record
cashRec RECORD; -- cash record buffer
itemRec RECORD; -- item record buffer
itemTypes TEXT DEFAULT ''(w|j|d|o|c|b)''; -- possible item types
funcName TEXT DEFAULT ''removeCash''; -- function name
dbg BOOLEAN DEFAULT True; -- debug print flag
BEGIN
IF dbg THEN
RAISE NOTICE ''% ()'', funcName;
END IF;
SELECT INTO cashRec order_num, ref FROM cash WHERE recid = cash_recid;
IF NOT FOUND THEN
RAISE EXCEPTION
''%: Cannot find a cash record referenced by %.'', funcName,
cash_recid;
END IF;
/* Loop through the item records linked to this cash record. */
FOR itemRec IN SELECT recid, item_type FROM item
WHERE order_num = cashRec.order_num
AND ref = cashRec.ref
AND item_type ~* itemTypes ORDER BY ref
LOOP
/* For type C, simply set the apply amount to zero and link to the
* value of olink. */
IF itemRec.item_type ~* ''c'' THEN
UPDATE item SET apply_amt = 0 WHERE recid = itemRec.recid;
IF NOT FOUND THEN
RAISE EXCEPTION
''%: Cannot update apply_amt for item %.'', funcName,
itemRec.recid;
END IF;
ELSE
/* Delete all other item types. */
DELETE item WHERE recid = itemRec.recid;
IF NOT FOUND THEN
RAISE EXCEPTION
''%: Cannot delete item record %.'', funcName,
itemRec.recid;
END IF;
END IF;
END LOOP;
/* Now, update the cash record setting batch and chkno to null. */
UPDATE cash SET chkno = NULL, batch = NULL
WHERE recid = cash_recid;
IF NOT FOUND THEN
RAISE EXCEPTION
''%: Unable to update cash record %.'', funcName, cash_recid;
END IF;
RETURN;
END;
' LANGUAGE plpgsql EXTERNAL SECURITY DEFINER;
There are trigger updates involved in this process. Setting apply_amt to zero
on the line item record causes an update to be made to the cash record linked
to the item record subtracting the value of apply_amt from a total applied
column in the cash record. Is this why the cash record is updated first?
Also, cash.batch and cash.chkno are the two components of a UNIQUE index.
Does this have something to do with it?
Any insight anyone can give would be greatly appreciated.
--
Quote: 81
"Government does not solve problems; it subsidizes them."
--Ronald Reagan
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Order of Update
@ 2006-03-18 14:25 Terry Lee Tucker <terry@esc1.com>
parent: Terry Lee Tucker <terry@esc1.com>
0 siblings, 0 replies; 15+ messages in thread
From: Terry Lee Tucker @ 2006-03-18 14:25 UTC (permalink / raw)
To: pgsql-general
Heck, I forgot version information:
rnd=# select version();
version
--------------------------------------------------------------------------------------------------------------
PostgreSQL 7.4.6 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC) 3.2.3
20030502 (Red Hat Linux 3.2.3-49)
(1 row)
On Saturday 18 March 2006 09:16 am, Terry Lee Tucker saith:
> Hello List:
.
.
.
^ permalink raw reply [nested|flat] 15+ messages in thread
* Order of update
@ 2025-04-20 09:10 Peter J. Holzer <hjp-pgsql@hjp.at>
0 siblings, 2 replies; 15+ messages in thread
From: Peter J. Holzer @ 2025-04-20 09:10 UTC (permalink / raw)
To: pgsql-general
I've just read Laurenz' blog post about the differences between Oracle
and PostgreSQL[1].
One of the differences is that something like
UPDATE tab SET id = id + 1;
tends to fail on PostgreSQL because the the primary key constraint is
checked for every row, so it will stumble over the temporary conflicts.
The solution is to define the constraint as deferrable.
But that got me to thinking about different ways ...
There won't be a conflict if the ids are updated in descending order.
Is there a way to force PostgreSQL to update the rows in a specific
order?
I came up with
with a as (select id from t where id > 50 order by id desc)
update t set id = a.id+1 from a where t.id = a.id;
which works in my simple test case, but it doesn't look like it's
guaranteed to work. The implicit join in «update t ... from a» could
produce rows in any order, especially for large tables.
So, is there a better way?
hjp
[1] https://www.cybertec-postgresql.com/en/comparison-of-the-transaction-systems-of-oracle-and-postgresq...
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
Attachments:
[application/pgp-signature] signature.asc (832B, ../../20250420091033.n437fdrkihtjrncd@hjp.at/2-signature.asc)
download
^ permalink raw reply [nested|flat] 15+ messages in thread
* Order of update
@ 2025-04-20 09:34 Thiemo Kellner <thiemo@gelassene-pferde.biz>
parent: Peter J. Holzer <hjp-pgsql@hjp.at>
1 sibling, 2 replies; 15+ messages in thread
From: Thiemo Kellner @ 2025-04-20 09:34 UTC (permalink / raw)
To: pgsql-general@lists.postgresql.org
Very interesting. But is the sort overhead worth it? Why not make the constraint deferrable before the update and switch back afterwards?
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Order of update
@ 2025-04-20 10:59 Peter J. Holzer <hjp-pgsql@hjp.at>
parent: Thiemo Kellner <thiemo@gelassene-pferde.biz>
1 sibling, 1 reply; 15+ messages in thread
From: Peter J. Holzer @ 2025-04-20 10:59 UTC (permalink / raw)
To: pgsql-general@lists.postgresql.org
On 2025-04-20 11:34:56 +0200, Thiemo Kellner wrote:
> Very interesting. But is the sort overhead worth it? Why not make the
> constraint deferrable before the update and switch back afterwards?
Mostly idle curiosity whether that's possible at all.
But there might be other reasons why you want to do updates in a
predictable order. For example to prevent deadlocks.
hjp
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
Attachments:
[application/pgp-signature] signature.asc (832B, ../../20250420105906.ya2safyc66vhi7j3@hjp.at/2-signature.asc)
download
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Order of update
@ 2025-04-20 14:03 Thiemo Kellner <thiemo@gelassene-pferde.biz>
parent: Peter J. Holzer <hjp-pgsql@hjp.at>
0 siblings, 0 replies; 15+ messages in thread
From: Thiemo Kellner @ 2025-04-20 14:03 UTC (permalink / raw)
To: pgsql-general@lists.postgresql.org
Hm, deadlocks preventing order by. Never had that problem. Then again, I mostly have Oracle experience and no need for complicated updates. If I had, I'd rather think of chunking updates and orchestrate those before ordering within updates.
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Order of update
@ 2025-04-20 14:28 Ron Johnson <ronljohnsonjr@gmail.com>
parent: Thiemo Kellner <thiemo@gelassene-pferde.biz>
1 sibling, 1 reply; 15+ messages in thread
From: Ron Johnson @ 2025-04-20 14:28 UTC (permalink / raw)
To: pgsql-general
On Sun, Apr 20, 2025 at 5:35 AM Thiemo Kellner <thiemo@gelassene-pferde.biz>
wrote:
> Very interesting. But is the sort overhead worth it? Why not make the
> constraint deferrable before the update and switch back afterwards?
>
The role which runs the UPDATE might not have the priv to ALTER TABLE ...
ALTER CONSTRAINT.
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Order of update
@ 2025-04-20 14:52 Thiemo Kellner <thiemo@gelassene-pferde.biz>
parent: Ron Johnson <ronljohnsonjr@gmail.com>
0 siblings, 0 replies; 15+ messages in thread
From: Thiemo Kellner @ 2025-04-20 14:52 UTC (permalink / raw)
To: pgsql-general@lists.postgresql.org
Might that be a feature of or a flaw in the application design? I opt for the latter. Any application that needs updates, be it only in emergency cases, should take that into account.
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Order of update
@ 2025-04-20 15:28 Adrian Klaver <adrian.klaver@aklaver.com>
parent: Peter J. Holzer <hjp-pgsql@hjp.at>
1 sibling, 1 reply; 15+ messages in thread
From: Adrian Klaver @ 2025-04-20 15:28 UTC (permalink / raw)
To: Peter J. Holzer <hjp-pgsql@hjp.at>; pgsql-general
On 4/20/25 02:10, Peter J. Holzer wrote:
> I've just read Laurenz' blog post about the differences between Oracle
> and PostgreSQL[1].
>
> One of the differences is that something like
>
> UPDATE tab SET id = id + 1;
>
> tends to fail on PostgreSQL because the the primary key constraint is
> checked for every row, so it will stumble over the temporary conflicts.
>
> The solution is to define the constraint as deferrable.
>
> But that got me to thinking about different ways ...
>
> There won't be a conflict if the ids are updated in descending order.
> Is there a way to force PostgreSQL to update the rows in a specific
> order?
>
> I came up with
>
> with a as (select id from t where id > 50 order by id desc)
> update t set id = a.id+1 from a where t.id = a.id;
>
> which works in my simple test case, but it doesn't look like it's
> guaranteed to work. The implicit join in «update t ... from a» could
> produce rows in any order, especially for large tables.
My read of this is that for the duration of the query a temporary table
a is create that is ordered on `id desc` and that '... from a where t.id
= a.id' will apply that order to the selection of t.id.
As example:
create table id_update(id integer primary key);
insert into id_update select a from generate_series(1, 100000) as t(a);
INSERT 0 100000
-- id(s) are temporarily in order.
update id_update set id = id where id between 50000 and 60000;
UPDATE 10001
-- The above move the 10001 values to 'end' of id_update
with a as (select id from id_update where id > 100 order by id desc)
update id_update as t set id = a.id + 1 from a where t.id = a.id;
UPDATE 99900
-- The UPDATE works even though the t.id(s) in id_update are not ordered
-- by id
>
> So, is there a better way?
>
> hjp
>
>
> [1] https://www.cybertec-postgresql.com/en/comparison-of-the-transaction-systems-of-oracle-and-postgresq...
>
--
Adrian Klaver
adrian.klaver@aklaver.com
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Order of update
@ 2025-04-21 08:47 Peter J. Holzer <hjp-pgsql@hjp.at>
parent: Adrian Klaver <adrian.klaver@aklaver.com>
0 siblings, 1 reply; 15+ messages in thread
From: Peter J. Holzer @ 2025-04-21 08:47 UTC (permalink / raw)
To: pgsql-general@lists.postgresql.org
On 2025-04-20 08:28:22 -0700, Adrian Klaver wrote:
> On 4/20/25 02:10, Peter J. Holzer wrote:
> > I've just read Laurenz' blog post about the differences between Oracle
> > and PostgreSQL[1].
> >
> > One of the differences is that something like
> >
> > UPDATE tab SET id = id + 1;
> >
> > tends to fail on PostgreSQL because the the primary key constraint is
> > checked for every row, so it will stumble over the temporary conflicts.
> >
> > The solution is to define the constraint as deferrable.
> >
> > But that got me to thinking about different ways ...
> >
> > There won't be a conflict if the ids are updated in descending order.
> > Is there a way to force PostgreSQL to update the rows in a specific
> > order?
> >
> > I came up with
> >
> > with a as (select id from t where id > 50 order by id desc)
> > update t set id = a.id+1 from a where t.id = a.id;
> >
> > which works in my simple test case, but it doesn't look like it's
> > guaranteed to work. The implicit join in «update t ... from a» could
> > produce rows in any order, especially for large tables.
>
> My read of this
Your read of the query, the PostgreSQL source or the SQL standard?
> is that for the duration of the query a temporary table a is create
> that is ordered on `id desc` and that '... from a where t.id = a.id'
> will apply that order to the selection of t.id.
Yes, that's the intention. In as I wrote it did work in my simple tests.
But is it guaranteed to work? Is there anything in the standard that
says that the order has to be preserved? Or failing that, is that the
way it's currently implemented and there are reasons to assume that it
will never be changed?
> As example:
>
> create table id_update(id integer primary key);
>
> insert into id_update select a from generate_series(1, 100000) as t(a);
> INSERT 0 100000
>
> -- id(s) are temporarily in order.
>
> update id_update set id = id where id between 50000 and 60000;
> UPDATE 10001
>
> -- The above move the 10001 values to 'end' of id_update
>
> with a as (select id from id_update where id > 100 order by id desc) update
> id_update as t set id = a.id + 1 from a where t.id = a.id;
> UPDATE 99900
I note that this produces a hash join:
#v+
╔═══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╗
║ QUERY PLAN ║
╟───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╢
║ Update on id_update t (cost=3179.42..8662.63 rows=0 width=0) ║
║ -> Hash Join (cost=3179.42..8662.63 rows=99899 width=38) ║
║ Hash Cond: (a.id = t.id) ║
║ -> Subquery Scan on a (cost=0.42..4971.64 rows=99899 width=32) ║
║ -> Index Only Scan Backward using id_update_pkey on id_update (cost=0.42..3972.65 rows=99899 width=4) ║
║ Index Cond: (id > 100) ║
║ -> Hash (cost=1929.00..1929.00 rows=100000 width=10) ║
║ -> Seq Scan on id_update t (cost=0.00..1929.00 rows=100000 width=10) ║
╚═══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╝
#v-
If the hash was the other way around it wouldn't work.
So let's try if we can get the optimizer to flip the plan by changing
the number of updated rows.
[a few minutes later]
#v+
hjp=> explain
with a as (select id from id_update where id > 90000 order by id desc)
update id_update as t set id = a.id + 1 from a where a.id = t.id;
╔════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╗
║ QUERY PLAN ║
╟────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╢
║ Update on id_update t (cost=732.53..2675.61 rows=0 width=0) ║
║ -> Hash Join (cost=732.53..2675.61 rows=10006 width=38) ║
║ Hash Cond: (t.id = a.id) ║
║ -> Seq Scan on id_update t (cost=0.00..1443.00 rows=100000 width=10) ║
║ -> Hash (cost=607.46..607.46 rows=10006 width=32) ║
║ -> Subquery Scan on a (cost=0.29..607.46 rows=10006 width=32) ║
║ -> Index Only Scan Backward using id_update_pkey on id_update (cost=0.29..507.40 rows=10006 width=4) ║
║ Index Cond: (id > 90000) ║
╚════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╝
#v-
Looks like we got it.
And indeed:
#v+
hjp=> with a as (select id from id_update where id > 90000 order by id desc)
update id_update as t set id = a.id + 1 from a where a.id = t.id;
ERROR: duplicate key value violates unique constraint "id_update_pkey"
DETAIL: Key (id)=(90002) already exists.
#v-
So, obviously that isn't guaranteed to work.
hjp
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
Attachments:
[application/pgp-signature] signature.asc (832B, ../../20250421084717.4edbhu6a7duiqw42@hjp.at/2-signature.asc)
download
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Order of update
@ 2025-04-21 15:43 Adrian Klaver <adrian.klaver@aklaver.com>
parent: Peter J. Holzer <hjp-pgsql@hjp.at>
0 siblings, 1 reply; 15+ messages in thread
From: Adrian Klaver @ 2025-04-21 15:43 UTC (permalink / raw)
To: pgsql-general@lists.postgresql.org
On 4/21/25 01:47, Peter J. Holzer wrote:
>
> If the hash was the other way around it wouldn't work.
>
> So let's try if we can get the optimizer to flip the plan by changing
> the number of updated rows.
>
> [a few minutes later]
>
> #v+
> hjp=> explain
> with a as (select id from id_update where id > 90000 order by id desc)
> update id_update as t set id = a.id + 1 from a where a.id = t.id;
> ╔════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╗
> ║ QUERY PLAN ║
> ╟────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╢
> ║ Update on id_update t (cost=732.53..2675.61 rows=0 width=0) ║
> ║ -> Hash Join (cost=732.53..2675.61 rows=10006 width=38) ║
> ║ Hash Cond: (t.id = a.id) ║
> ║ -> Seq Scan on id_update t (cost=0.00..1443.00 rows=100000 width=10) ║
> ║ -> Hash (cost=607.46..607.46 rows=10006 width=32) ║
> ║ -> Subquery Scan on a (cost=0.29..607.46 rows=10006 width=32) ║
> ║ -> Index Only Scan Backward using id_update_pkey on id_update (cost=0.29..507.40 rows=10006 width=4) ║
> ║ Index Cond: (id > 90000) ║
> ╚════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════╝
> #v-
>
> Looks like we got it.
>
> And indeed:
>
> #v+
> hjp=> with a as (select id from id_update where id > 90000 order by id desc)
> update id_update as t set id = a.id + 1 from a where a.id = t.id;
> ERROR: duplicate key value violates unique constraint "id_update_pkey"
> DETAIL: Key (id)=(90002) already exists.
> #v-
>
> So, obviously that isn't guaranteed to work.
I read from here:
https://www.postgresql.org/docs/current/sql-update.html
"Use of an ORDER BY clause allows the command to prioritize which rows
will be updated; it can also prevent deadlock with other update
operations if they use the same ordering."
I went back to those docs and realized I had missed the FOR UPDATE in
the example.
explain with a as (select id from id_update where id > 90000 order by id
desc for update) update id_update as t set id = a.id + 1 from a where
a.id = t.id;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------
Update on id_update t (cost=3609.71..3856.94 rows=0 width=0)
CTE a
-> LockRows (cost=0.29..872.71 rows=9840 width=10)
-> Index Scan Backward using id_update_pkey on id_update
(cost=0.29..774.31 rows=9840 width=10)
Index Cond: (id > 90000)
-> Hash Join (cost=2737.00..2984.23 rows=9840 width=38)
Hash Cond: (a.id = t.id)
-> CTE Scan on a (cost=0.00..196.80 rows=9840 width=32)
-> Hash (cost=1487.00..1487.00 rows=100000 width=10)
-> Seq Scan on id_update t (cost=0.00..1487.00
rows=100000 width=10)
(10 rows)
and then:
with a as (select id from id_update where id > 90000 order by id desc
for update) update id_update as t set id = a.id + 1 from a where a.id =
t.id;
UPDATE 10000
Though at this point I would agree with you on the no guarantee point.
>
> hjp
>
--
Adrian Klaver
adrian.klaver@aklaver.com
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Order of update
@ 2025-04-21 16:12 Thiemo Kellner <thiemo@gelassene-pferde.biz>
parent: Adrian Klaver <adrian.klaver@aklaver.com>
0 siblings, 2 replies; 15+ messages in thread
From: Thiemo Kellner @ 2025-04-21 16:12 UTC (permalink / raw)
To: pgsql-general@lists.postgresql.org
I wonder if that is a corner case. Updating a unique key sounds to me like a design flaw in the first place.
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Order of update
@ 2025-04-21 16:44 Adrian Klaver <adrian.klaver@aklaver.com>
parent: Thiemo Kellner <thiemo@gelassene-pferde.biz>
1 sibling, 1 reply; 15+ messages in thread
From: Adrian Klaver @ 2025-04-21 16:44 UTC (permalink / raw)
To: Thiemo Kellner <thiemo@gelassene-pferde.biz>; pgsql-general@lists.postgresql.org
On 4/21/25 09:12, Thiemo Kellner wrote:
> I wonder if that is a corner case. Updating a unique key sounds to me like a design flaw in the first place.
>
Check out this the thread below for discussion on that topic:
https://www.postgresql.org/message-id/dkbnfi$7g5$1@sea.gmane.org
--
Adrian Klaver
adrian.klaver@aklaver.com
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Order of update
@ 2025-04-21 17:58 Thiemo Kellner <thiemo@gelassene-pferde.biz>
parent: Adrian Klaver <adrian.klaver@aklaver.com>
0 siblings, 0 replies; 15+ messages in thread
From: Thiemo Kellner @ 2025-04-21 17:58 UTC (permalink / raw)
To: pgsql-generallists.postgresql.org <pgsql-general@lists.postgresql.org>
Thanks for the pointer. I feel my doubts reflected. For such reasons, I prefer the UUID as surrogate key. No point in trying to establish an order or even id arithmetics.
21.04.2025 18:44:27 Adrian Klaver <adrian.klaver@aklaver.com>:
> On 4/21/25 09:12, Thiemo Kellner wrote:
>> I wonder if that is a corner case. Updating a unique key sounds to me like a design flaw in the first place.
>>
>
> Check out this the thread below for discussion on that topic:
>
> https://www.postgresql.org/message-id/dkbnfi$7g5$1@sea.gmane.org
>
> --
> Adrian Klaver
> adrian.klaver@aklaver.com
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: Order of update
@ 2025-04-24 06:26 Peter J. Holzer <hjp-pgsql@hjp.at>
parent: Thiemo Kellner <thiemo@gelassene-pferde.biz>
1 sibling, 0 replies; 15+ messages in thread
From: Peter J. Holzer @ 2025-04-24 06:26 UTC (permalink / raw)
To: pgsql-general@lists.postgresql.org
On 2025-04-21 18:12:13 +0200, Thiemo Kellner wrote:
> I wonder if that is a corner case. Updating a unique key sounds to me like a design flaw in the first place.
I agree that changing a surrogate key is almost always a mistake.
But there might be situations where a column should be unique but isn't
an id.
For example, many years ago it was a popular[1] programming pattern to
represent trees as nested ranges (i.e. if two children of a parent had
the ranges (a, b) and (b+1, c) then the parent had (a-1, c+1).
Insert-operations then need to update those columns. You want an index
on those columns (since you search for them a lot), and you might want
to make it a unique index, since that covers part of the invariant
(although not the complete invariant). If you do that you run into the
update problem.
There are probably other use-cases. Anything where you need a unique
order which can change, I guess?
Anyway, I don't have a pressing need for this, as I said I was just
curious.
hjp
[1] Mostly in MySQL I think, since it didn't have recursive queries of
any kind.
--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
Attachments:
[application/pgp-signature] signature.asc (832B, ../../20250424062609.uzyq3swxeg5lh54u@hjp.at/2-signature.asc)
download
^ permalink raw reply [nested|flat] 15+ messages in thread
end of thread, other threads:[~2025-04-24 06:26 UTC | newest]
Thread overview: 15+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2006-03-18 14:16 Order of Update Terry Lee Tucker <terry@esc1.com>
2006-03-18 14:25 ` Terry Lee Tucker <terry@esc1.com>
2025-04-20 09:10 Order of update Peter J. Holzer <hjp-pgsql@hjp.at>
2025-04-20 09:34 ` Order of update Thiemo Kellner <thiemo@gelassene-pferde.biz>
2025-04-20 10:59 ` Re: Order of update Peter J. Holzer <hjp-pgsql@hjp.at>
2025-04-20 14:03 ` Re: Order of update Thiemo Kellner <thiemo@gelassene-pferde.biz>
2025-04-20 14:28 ` Re: Order of update Ron Johnson <ronljohnsonjr@gmail.com>
2025-04-20 14:52 ` Re: Order of update Thiemo Kellner <thiemo@gelassene-pferde.biz>
2025-04-20 15:28 ` Re: Order of update Adrian Klaver <adrian.klaver@aklaver.com>
2025-04-21 08:47 ` Re: Order of update Peter J. Holzer <hjp-pgsql@hjp.at>
2025-04-21 15:43 ` Re: Order of update Adrian Klaver <adrian.klaver@aklaver.com>
2025-04-21 16:12 ` Re: Order of update Thiemo Kellner <thiemo@gelassene-pferde.biz>
2025-04-21 16:44 ` Re: Order of update Adrian Klaver <adrian.klaver@aklaver.com>
2025-04-21 17:58 ` Re: Order of update Thiemo Kellner <thiemo@gelassene-pferde.biz>
2025-04-24 06:26 ` Re: Order of update Peter J. Holzer <hjp-pgsql@hjp.at>
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