Improve cleanup in rolenames test
Drop test_schema at the end, because that otherwise interferes with the
collate.linux.utf8 test.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/6a9c51810f1db08de4033cbecd95a83d7b364fd1
Modified Files
--
src/test/regress
Tag refs/tags/REL9_6_BETA2 was created.
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Update comment about allowing GUCs to change scanning.
Reported-by: David G. Johnston
Discussion: cakfquwzzvnxwsq9tntvl+uyudkggv91zr_agtpxqhrwmwqr...@mail.gmail.com
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/3e9df858f0de5f1a37c71f24373caf8c870f6993
Modified Fi
Document that dependency tracking doesn't consider function bodies.
If there's anyplace in our SGML docs that explains this behavior, I can't
find it right at the moment. Add an explanation in "Dependency Tracking"
which seems like the authoritative place for such a discussion. Per
gripe from Mi
Document that dependency tracking doesn't consider function bodies.
If there's anyplace in our SGML docs that explains this behavior, I can't
find it right at the moment. Add an explanation in "Dependency Tracking"
which seems like the authoritative place for such a discussion. Per
gripe from Mi
Document that dependency tracking doesn't consider function bodies.
If there's anyplace in our SGML docs that explains this behavior, I can't
find it right at the moment. Add an explanation in "Dependency Tracking"
which seems like the authoritative place for such a discussion. Per
gripe from Mi
Document that dependency tracking doesn't consider function bodies.
If there's anyplace in our SGML docs that explains this behavior, I can't
find it right at the moment. Add an explanation in "Dependency Tracking"
which seems like the authoritative place for such a discussion. Per
gripe from Mi
Document that dependency tracking doesn't consider function bodies.
If there's anyplace in our SGML docs that explains this behavior, I can't
find it right at the moment. Add an explanation in "Dependency Tracking"
which seems like the authoritative place for such a discussion. Per
gripe from Mi
Document that dependency tracking doesn't consider function bodies.
If there's anyplace in our SGML docs that explains this behavior, I can't
find it right at the moment. Add an explanation in "Dependency Tracking"
which seems like the authoritative place for such a discussion. Per
gripe from Mi
Refactor planning of projection steps that don't need a Result plan node.
The original upper-planner-pathification design (commit 3fc6e2d7f5b652b4)
assumed that we could always determine during Path formation whether or not
we would need a Result plan node to perform projection of a targetlist.
Th
I wrote:
> I had hoped that this would result in simplifying create_projection_plan
> so that it just makes a Result or not according to what
> create_projection_path decided, but there's one regression test case that
> fails (in the sense of showing a Result in the plan that isn't really
> needed)
I wrote:
> If we keep it like this, we definitely ought to refactor things so that
> fewer places are aware of the possibility of the Result getting omitted.
> Maybe push that logic into create_projection_path? If we did, we might
> not need a separate apply_projection_to_path function at all? To
12 matches
Mail list logo
