@Moderators: I am reposting this because the original from 22 December
apparently didn't arrive on the list.
I was trying to make Postgresql use a trigram gist index on a varchar
field, but to no avail.
Specifically, I was trying to replicate what is done in this blog post:
http://www.postgresonl
Hi everyone;
I recently discovered that subselects in update statements don't assume
that the select is for update of the updating table.
For example, if I do this:
CREATE TABLE foo (
test int primary key,
);
INSERT INTO foo VALUES (1);
then in one session:
BEGIN;
UPDATE foo SET test = 2 W
On Sunday, January 06, 2013 7:48 AM Chris Travers wrote:
> I recently discovered that subselects in update statements don't assume that
> the select is for update of the updating table.
> For example, if I do this:
> CREATE TABLE foo (
> test int primary key,
> );
> INSERT INTO foo VALUES
On Sunday, January 06, 2013 11:10 AM Amit kapila wrote:
On Sunday, January 06, 2013 7:48 AM Chris Travers wrote:
>> Is there a reason why we don't do locking this way? (i.e. where on UPDATE
>> foo, all rows selected from foo during the
>> update are locked unless the subselect specifically s
2013-01-06 03:18 keltezéssel, Chris Travers írta:
Hi everyone;
I recently discovered that subselects in update statements don't assume that the select
is for update of the updating table.
For example, if I do this:
CREATE TABLE foo (
test int primary key,
);
INSERT INTO foo VALUES (1);
