I wrote:
Attached are patches meant for HEAD and 9.2-9.4 respectively.
BTW, has anyone got an opinion about whether to stick the full fix into
9.4? The argument for, of course, is that we'd get the full fix out to
the public a year sooner. The argument against is that someone might
have
On Mon, Nov 10, 2014 at 10:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Attached are patches meant for HEAD and 9.2-9.4 respectively.
BTW, has anyone got an opinion about whether to stick the full fix into
9.4? The argument for, of course, is that we'd get the full fix out to
the
Tom Lane-2 wrote
I wrote:
Attached are patches meant for HEAD and 9.2-9.4 respectively.
BTW, has anyone got an opinion about whether to stick the full fix into
9.4? The argument for, of course, is that we'd get the full fix out to
the public a year sooner. The argument against is that
Yes, it's late beta, but especially if we're pushing json/jsonb usage
as a major feature of this release, I'd say remove surprising cases
now. It's late beta, but that's what beta is for, the last chance for
bug fixes, before we live w/ it for the support life of the release.
The affected class
On 11/10/2014 10:19 AM, Robert Haas wrote:
On Mon, Nov 10, 2014 at 10:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
Attached are patches meant for HEAD and 9.2-9.4 respectively.
BTW, has anyone got an opinion about whether to stick the full fix into
9.4? The argument for, of course, is
Robert Haas robertmh...@gmail.com writes:
On Mon, Nov 10, 2014 at 10:11 AM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, has anyone got an opinion about whether to stick the full fix into
9.4?
I think we should put the full fix in 9.4.
Since nobody spoke against that, I've put the full fix into
I wrote:
We could reduce the risks involved by narrowing the cases in which
ExecEvalWholeRowVar will replace field names it got from the input.
I'd be inclined to propose:
1. If Var is of a named composite type, use *exactly* the field names
associated with that type. (This avoids the need
On Fri, Nov 7, 2014 at 11:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Thoughts?
I'm not sure whether this is safe enough to back-patch, but it seems
like we should probably plan to back-patch *something*, because the
status quo isn't great either.
--
Robert Haas
EnterpriseDB:
On 11/08/2014 09:26 AM, Robert Haas wrote:
On Fri, Nov 7, 2014 at 11:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Thoughts?
I'm not sure whether this is safe enough to back-patch, but it seems
like we should probably plan to back-patch *something*, because the
status quo isn't great either.
Andrew Dunstan and...@dunslane.net writes:
On 11/08/2014 09:26 AM, Robert Haas wrote:
I'm not sure whether this is safe enough to back-patch, but it seems
like we should probably plan to back-patch *something*, because the
status quo isn't great either.
I confirm that Tom's patch does indeed
On 11/08/2014 11:24 AM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 11/08/2014 09:26 AM, Robert Haas wrote:
I'm not sure whether this is safe enough to back-patch, but it seems
like we should probably plan to back-patch *something*, because the
status quo isn't great either.
Andrew Dunstan and...@dunslane.net writes:
On 11/08/2014 11:24 AM, Tom Lane wrote:
That seems like a pretty silly move: it wouldn't actually fix anything,
and it would break cases that perhaps are acceptable to users today.
What evidence do you have that it might be acceptable to today's
Tom Lane t...@sss.pgh.pa.us
Andrew Dunstan and...@dunslane.net writes:
I assume that's what you would propose for just the stable branches, and
that going forward we'd always use the aliases from the RTE?
That would be my druthers. But given the lack of complaints, maybe we
should just
On 11/08/2014 12:14 PM, Tom Lane wrote:
I assume that's what you would propose for just the stable branches, and
that going forward we'd always use the aliases from the RTE?
That would be my druthers. But given the lack of complaints, maybe we
should just stick to the
Andrew Dunstan and...@dunslane.net writes:
On 11/08/2014 12:14 PM, Tom Lane wrote:
That would be my druthers. But given the lack of complaints, maybe we
should just stick to the more-backwards-compatible behavior until someone
does complain. Thoughts?
Wouldn't that would mean we might not
On 11/08/2014 12:40 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 11/08/2014 12:14 PM, Tom Lane wrote:
That would be my druthers. But given the lack of complaints, maybe we
should just stick to the more-backwards-compatible behavior until someone
does complain. Thoughts?
Oh, some more fun: a RowExpr that's labeled with a named composite type
(rather than RECORD) has the same issue of not respecting aliases.
Continuing previous example with table foo:
regression=# create view vv as select * from foo;
CREATE VIEW
regression=# select row_to_json(q) from vv q;
I've no opinion on the not respecting aliases aspect of this, but both
the hstore and json emtpy keys case breaks the format: it's duplicate keys
that collapse to a single value, and expected keynames are missing.
The insidious bit about this bug though is that it works fine during testing
with
On 11/08/2014 04:19 PM, Ross Reedstrom wrote:
I've no opinion on the not respecting aliases aspect of this, but both
the hstore and json emtpy keys case breaks the format: it's duplicate keys
that collapse to a single value, and expected keynames are missing.
The insidious bit about this bug
This is a serious bug in 9.3.5 and 9.4 beta3:
row_to_json() yields empty strings for json keys if the data is
fulfilled by an index only scan.
Example:
testjson=# select count(*) from document_acl;
count
---
426
(1 row)
testjson=# SELECT row_to_json(combined_rows) FROM (
SELECT uuid,
On 11/07/2014 10:51 AM, Ross Reedstrom wrote:
This is a serious bug in 9.3.5 and 9.4 beta3:
row_to_json() yields empty strings for json keys if the data is
fulfilled by an index only scan.
Example:
testjson=# select count(*) from document_acl;
count
---
426
(1 row)
testjson=#
On 11/07/2014 11:17 AM, Andrew Dunstan wrote:
On 11/07/2014 10:51 AM, Ross Reedstrom wrote:
This is a serious bug in 9.3.5 and 9.4 beta3:
row_to_json() yields empty strings for json keys if the data is
fulfilled by an index only scan.
Example:
testjson=# select count(*) from document_acl;
Andrew Dunstan and...@dunslane.net writes:
On 11/07/2014 10:51 AM, Ross Reedstrom wrote:
row_to_json() yields empty strings for json keys if the data is
fulfilled by an index only scan.
Could this be a bug in lookup_rowtype_tupdesc()?
I think this is probably a variant of bug #11210, in
On 11/07/2014 04:59 PM, Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
On 11/07/2014 10:51 AM, Ross Reedstrom wrote:
row_to_json() yields empty strings for json keys if the data is
fulfilled by an index only scan.
Could this be a bug in lookup_rowtype_tupdesc()?
I think this is
Andrew Dunstan and...@dunslane.net writes:
On 11/07/2014 04:59 PM, Tom Lane wrote:
I think this is probably a variant of bug #11210, in which the problem is
that tupledescs bubbled up from inheritance children never get column
names assigned to them. I've been speculating about ways to fix
25 matches
Mail list logo
