Re: [GENERAL] Chaining inserts ... This would be cool

2012-04-23 Thread Nick Apperson
You can have INSERT ... SELECT RETURNING ... as a query in Postgres. The RETURNING applies to the INSERT. See: CREATE TABLE foo(i INT); INSERT INTO foo(i) SELECT generate_series(1,5) RETURNING i; Anyway, CTEs might work, but I can't see any good way to pass the association through without th

Re: [GENERAL] Chaining inserts ... This would be cool

2012-04-23 Thread Chris Angelico
On Tue, Apr 24, 2012 at 11:30 AM, David Fetter wrote: > On Tue, Apr 24, 2012 at 08:12:10AM +1000, Chris Angelico wrote: >> Of course, the question I never asked (never bothered to, really) >> was: Is it really any better than simply doing the first insert and >> retrieving the ID in my application

Re: [GENERAL] Chaining inserts ... This would be cool

2012-04-23 Thread David Fetter
On Tue, Apr 24, 2012 at 08:12:10AM +1000, Chris Angelico wrote: > On Tue, Apr 24, 2012 at 6:49 AM, Nick Apperson wrote: > > There are obviously workarounds for this, but I'm wondering why > > the following query shouldn't work. It seems like it should. With > > MVCC already present on the back-end

Re: [GENERAL] Chaining inserts ... This would be cool

2012-04-23 Thread Chris Angelico
On Tue, Apr 24, 2012 at 6:49 AM, Nick Apperson wrote: > There are obviously workarounds for this, but I'm wondering why the > following query shouldn't work. It seems like it should. With MVCC already > present on the back-end, I can't see any reason other than additional > parsing routines that t

Re: [GENERAL] Chaining inserts ... This would be cool

2012-04-23 Thread Thom Brown
On 23 April 2012 21:49, Nick Apperson wrote: > There are obviously workarounds for this, but I'm wondering why the > following query shouldn't work. It seems like it should. With MVCC already > present on the back-end, I can't see any reason other than additional > parsing routines that this could

[GENERAL] Chaining inserts ... This would be cool

2012-04-23 Thread Nick Apperson
There are obviously workarounds for this, but I'm wondering why the following query shouldn't work. It seems like it should. With MVCC already present on the back-end, I can't see any reason other than additional parsing routines that this couldn't work: INSERT INTO old_login_id_to_new_account_id(

[GENERAL] Re: [HACKERS] Namespace of array of user defined types is confused by the parser in insert?

2012-04-23 Thread Andrew Dunstan
[redirected to pgsql-general] On 04/23/2012 09:42 AM, Krzysztof Nienartowicz wrote: Hello, Sorry for re-posting - I initially posted this in pgsql.sql - probably this group is more appropriate. pgsql-general probably would be best. -hackers is for discussion of internals and development, n

Re: [GENERAL] How to convert BYTEA (from decrypt) to TEXT?

2012-04-23 Thread Vincenzo Romano
2012/4/23 Vincenzo Romano : > Hi all. > I know that the output of a decrypt() call (from pgcrypto module) can > be safely converted to TEXT. > CAST( decrypt( data,key,'bf' ) as TEXT ) (and other variants) just doesn't > work. > How can I (possibly easily) do it? > Thanks. Found! It is on chapter

Re: [GENERAL] What is the different between pg_trgm search and FULL Text search?

2012-04-23 Thread Tomas Vondra
On 23 Duben 2012, 13:31, AI Rumman wrote: > What is the different between pg_trgm search and FULL Text search? > Anyone has idea on these, please let me know. pg_trgm performs "trigram matching" i.e. determines similarity of strings based on trigrams (three-character strings). It has no notion of

[GENERAL] What is the different between pg_trgm search and FULL Text search?

2012-04-23 Thread AI Rumman
What is the different between pg_trgm search and FULL Text search? Anyone has idea on these, please let me know.

[GENERAL] How to convert BYTEA (from decrypt) to TEXT?

2012-04-23 Thread Vincenzo Romano
Hi all. I know that the output of a decrypt() call (from pgcrypto module) can be safely converted to TEXT. CAST( decrypt( data,key,'bf' ) as TEXT ) (and other variants) just doesn't work. How can I (possibly easily) do it? Thanks. -- Sent via pgsql-general mailing list (pgsql-general@postgresql.o