Re: [HACKERS] TRAP: FailedAssertion("!(hassrf)", File:"nodeProjectSet.c", Line: 180)
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] TRAP: FailedAssertion("!(hassrf)", File:"nodeProjectSet.c", Line: 180) |
Дата | |
Msg-id | 20170201233653.wnc6f3x4rsgid2sq@alap3.anarazel.de обсуждение исходный текст |
Ответ на | [HACKERS] TRAP: FailedAssertion("!(hassrf)", File: "nodeProjectSet.c", Line:180) (Erik Rijkers <er@xs4all.nl>) |
Ответы |
Re: [HACKERS] TRAP: FailedAssertion("!(hassrf)", File: "nodeProjectSet.c", Line: 180)
|
Список | pgsql-hackers |
Hi, On 2017-02-02 00:09:03 +0100, Erik Rijkers wrote: > Something is broken in HEAD: Hm. Indeed. > drop table if exists t; > create table t(c text); > insert into t (c) values ( 'abc' ) ; > > select > regexp_split_to_array( > regexp_split_to_table( > c > , chr(13) || chr(10) ) > , '","' ) > as a > , > regexp_split_to_table( > c > , chr(13) || chr(10) > ) > as rw > from t > ; > > TRAP: FailedAssertion("!(hassrf)", File: "nodeProjectSet.c", Line: 180) > I realise the regexp* functions aren't doing anything particularly useful > anymore here; they did in the more complicated original (which I had used > for years). The issue is that we're generating ProjectSet nodes instead of Result for the top-level nodes - but we currently assume that ProjectSet nodes actually contain sets. I'm tentatively in favor of generating proper Result nodes in this case, rather than allowing this in ProjectSet - on the other hand, it works after removing that Assert(). Tom, do you have an opinion? Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: