_copyResult didn't copy subPlan structure completely. _copyAgg is still
busted, apparently because of changes from EXCEPT/INTERSECT patch
(get_agg_tlist_references is no longer sufficient to find all aggregates).
No time to look at that tonight, however.
so remove them from MergeJoin node. Hack together a partial
solution for commuted mergejoin operators --- yesterday
a mergejoin int4 = int8 would crash if the planner decided to
commute it, today it works. The planner's representation of
mergejoins really needs a rewrite though.
Also, further testing of mergejoin ops in opr_sanity regress test.
Pawel Pierscionek [pawel@astercity.net] reported about the
following case 1([SQL] drop table in pgsql).
Michael Contzen [mcontzen@dohle.com] reported about the
following case 2(PL/PGSQL bug using aggregates).
You can find it from pgsql-hackers archive.
1. PL/pgSQL can't execute UTILITY commands.
SPI_prepare() doesn't copy(save) the utilityStmt member of
Query type nodes,because copyObject() is not implemented
for nodes of (Create/Destroy etc)Stmt type.
2. Aggregates in PL/pgSQL cause wrong results.
...
It's a list including Aggreg type nodes which exist in
TargetList(i.e Aggreg type nodes are common to aggs
member list and TargetList).
AFAIC the common pointer is not copied to the same
pointer by copyObject() function.
In my patch I reconstruct aggs member node from
new(copied) Agg type node.
Is it proper to use set_agg_tlist_references() function to
reconstruct aggs member node for Agg type nodes ?
Thanks.
Hiroshi Inoue
Inoue@tpf.co.jp
below is the patch to have views to override the permission
checks for the accessed tables. Now we can do the following:
CREATE VIEW db_user AS SELECT
usename,
usesysid,
usecreatedb,
usetrace,
usecatupd,
'**********'::text as passwd,
valuntil
FROM pg_user;
REVOKE ALL ON pg_user FROM public;
REVOKE ALL ON db_user FROM public;
GRANT SELECT ON db_user TO public;
