On 11/20/2013 10:36 PM, Tom Lane wrote: > Craig Ringer <cr...@2ndquadrant.com> writes: >> I'm spending a lot of time staring at parse and plan trees at the >> moment, and I'm finding reading them rather cumbersome. > > Is there a particular reason you're doing that rather than looking at > EXPLAIN output? Only the latter is meant to be at all user-friendly.
Because I'm working on updatable security_barrier views using the approach outlined to the list earlier. EXPLAIN really doesn't do the trick for working on the guts of the rewriter. >> The same representation is used for storing rules. So it can't be >> changed for BC reasons and compactness/performance. > > We could in principle change to a different text representation for > stored rules. Compactness would be an issue if it were materially > bigger than the existing formatting, but offhand it seems like JSON > is morally equivalent to what we do now, no? > > If you think this is worthwhile, you might care to take a look at > outfuncs.c/readfuncs.c and figure out what it'd take to switch to > json-compatible formatting. I do think it might be worthwhile at some point, but once I remembered it was about more than just debug_print_ output - that DB performance is impacted - I realised it was not a topic for a quick and simple change. Benchmarking required, etc. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
