Added to TODO:
* Allow INSERT ... DELETE ... RETURNING, namely allow the DELETE ...
RETURNING to supply values to the INSERT
http://archives.postgresql.org/pgsql-hackers/2008-02/thrd2.php#00979
---
Jonah H. Harris
Hi Mark,
On Sun, Feb 24, 2008 at 10:21 PM, Mark Mielke [EMAIL PROTECTED] wrote:
I'm at PostgreSQL 8.3 for my production database and everything is
working great. I had no problems converting free text search from 8.2 to
8.3, and I really like the improvements.
I tried using insert ...
On Sun, Feb 24, 2008 at 10:39 PM, Guillaume Smet
[EMAIL PROTECTED] wrote:
On Sun, Feb 24, 2008 at 10:21 PM, Mark Mielke [EMAIL PROTECTED] wrote:
I'm at PostgreSQL 8.3 for my production database and everything is
working great. I had no problems converting free text search from 8.2 to
Hi all:
I'm at PostgreSQL 8.3 for my production database and everything is
working great. I had no problems converting free text search from 8.2 to
8.3, and I really like the improvements.
I tried using insert ... delete ... return ... and get a syntax error:
pccyber=# insert into
On Sun, Feb 24, 2008 at 4:21 PM, Mark Mielke [EMAIL PROTECTED] wrote:
I tried using insert ... delete ... return ... and get a syntax error:
Yeah...
In the past I've executed insert ... select and then the delete.
However, I believe there is race condition here as the delete may see
more
Jonah H. Harris [EMAIL PROTECTED] writes:
Not stupid, it doesn't work :) This was a limitation of the original
design based on (IIRC) executor-related issues.
There are definitional issues not only implementation ones; in
particular, in subquery-like cases it's entirely unclear how many times
On Sun, Feb 24, 2008 at 5:44 PM, Tom Lane [EMAIL PROTECTED] wrote:
Jonah H. Harris [EMAIL PROTECTED] writes:
Not stupid, it doesn't work :) This was a limitation of the original
design based on (IIRC) executor-related issues.
There are definitional issues not only implementation ones;
Tom Lane wrote:
Jonah H. Harris [EMAIL PROTECTED] writes:
Not stupid, it doesn't work :) This was a limitation of the original
design based on (IIRC) executor-related issues.
There are definitional issues not only implementation ones; in
particular, in subquery-like cases it's
Mark Mielke [EMAIL PROTECTED] writes:
I'm noticing a massive reduction in on disk storage required for my
database that I believe is primarily attributable due to Tom's reduced
overhead for short strings.
Twasn't my work; Greg Stark gets most of the credit for that one, and
you might be
