The following bug has been logged on the website:
Bug reference: 8226
Logged by: Denis de Bernardy
Email address: ddeberna...@yahoo.com
PostgreSQL version: 9.2.4
Operating system: OSX
Description:
It looks like unnest() in a select statement doesn't behave consistentl
On Wed, Jun 12, 2013 at 9:58 AM, wrote:
> denis=# select 1 as a, unnest('{2,3}'::int[]) as b, unnest('{4,5}'::int[])
set returning functions in the target list of the select don't behave
the way you're thinking. What you probably want to do is move the
unnest() to the FROM clause:
select 1 as a
On Wed, Jun 12, 2013 at 9:58 AM, wrote:
> denis=# select 1 as a, unnest('{2,3}'::int[]) as b, unnest('{4,5}'::int[])
set returning functions in the target list of the select don't behave
the way you're thinking. What you probably want to do is move the
unnest() to the FROM clause:
select 1 as a
The actual query was something like:
select id, person, unnest(groups) as grp from people
… where groups is a crazy column containing an array that needed to be joined
with another table. In this case, you cannot do your suggested solution, which
would look like this:
select id, person, grp fr
Hello
it is known old strange feature
http://postgresql.1045698.n5.nabble.com/Set-returning-functions-in-select-column-list-td5491544.html
Regards
Pavel Stehule
p.s. don't use this feature, it is strange - and we cannot change
behave due compatibility reasons.
2013/6/12 Denis de Bernardy :
On Wed, Jun 12, 2013 at 12:19:51PM +0200, Denis de Bernardy wrote:
> Methinks the behavior should be consistent. It should always do one
> (presumably like in the first statement) or the other (which leads to
> undefined behavior in the first statement).
It is consistent. You just assume it does s
On Wed, Jun 12, 2013 at 12:19:51PM +0200, Denis de Bernardy wrote:
> … where groups is a crazy column containing an array that needed to be
> joined with another table. In this case, you cannot do your suggested
> solution, which would look like this:
Missed this one.
You don't need to unpack to
The following bug has been logged on the website:
Bug reference: 8227
Logged by: Greg Brzezinski
Email address: g...@antrez.pl
PostgreSQL version: 9.2.4
Operating system: linux
Description:
postgres=# CREATE TABLE test( id int primary key, name text );
NOTICE: CREATE
g...@antrez.pl writes:
> Is it ok that we loose referential integrity by locking DELETE on table
> test_item ?
Yes. If you put a trigger on a table involved in an FK constraint, it's
your responsibility that the trigger doesn't break FK update operations.
regards, tom lan
