Re: [HACKERS] [GENERAL] Possible bug with row_to_json

2014-01-31 Thread Tom Lane
Bruce Momjian writes: > On Tue, Aug 13, 2013 at 05:34:12PM -0400, Tom Lane wrote: >> Further poking at this issue shows that there are related behaviors that >> aren't fixed by my proposed patch. > Where are we on this? Still have no idea how to fix the whole-row-Var case. We could fix some of

Re: [HACKERS] [GENERAL] Possible bug with row_to_json

2014-01-31 Thread Bruce Momjian
On Tue, Aug 13, 2013 at 05:34:12PM -0400, Tom Lane wrote: > Further poking at this issue shows that there are related behaviors that > aren't fixed by my proposed patch. The original complaint can be > replicated in the regression database like this: > > select row_to_json(i8) from (select q1 as

Re: [HACKERS] [GENERAL] Possible bug with row_to_json

2013-08-13 Thread Merlin Moncure
On Tue, Aug 13, 2013 at 4:34 PM, Tom Lane wrote: > Since this behavior can also be demonstrated in 9.2 (and maybe further > back using xml features?), I don't think we should consider it a > blocker bug for 9.3. I'm planning to set it on the back burner for > the moment and go worry about the pla

Re: [HACKERS] [GENERAL] Possible bug with row_to_json

2013-08-13 Thread Tom Lane
I wrote: > Jack Christensen writes: >> It ignored the rename. > I looked into this and found that the culprit is the optimization that > skips ExecProject() if a scan plan node is not doing any useful > projection. Further poking at this issue shows that there are related behaviors that aren't f

Re: [HACKERS] [GENERAL] Possible bug with row_to_json

2013-08-06 Thread Tom Lane
Jack Christensen writes: > jack=# create table player( > jack(# player_id serial primary key, > jack(# name varchar not null unique > jack(# ); > CREATE TABLE > jack=# insert into player(name) values('Jack'); > INSERT 0 1 > jack=# select row_to_json(t) > jack-# from ( > jack(# select player_