<div dir="ltr">On Fri, Apr 12, 2013 at 1:00 AM, Stephen Frost <span dir="ltr"><<a href="mailto:sfrost@snowman.net"
target="_blank">sfrost@snowman.net</a>></span>wrote:<br /><div class="gmail_extra"><div
class="gmail_quote"><blockquoteclass="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex">>Well, either they want that or they want that output more<br /><div class="im"> >
accessibly,and without all the baggage that pg_dump necessarily<br /> > brings to the table. pg_dump does a lot of
stuffthat's basically<br /> > designed for bulk operations, and often what people want is a way to<br /> > get,
say,the creation DDL for some object, without any locks than<br /> > the usual locks any transaction takes.<br /><br
/></div>Yes-being able to get that from a simple database function would be<br /> very nice. I wonder if some of
what'sbeen done with the "event"<br /> triggers would inform us about what that API should look like.<br
/></blockquote></div>Irecall discussions about reverse engineering of a parsed query tree in<br /></div><div
class="gmail_extra">theevent trigger threads but nothing has been committed I think. Also, you<br /></div><div
class="gmail_extra">need to consider that implementing such reverse engineering mechanism in<br />core might not be a
goodthing for new features and maintenance, as it<br />would mean that it is necessary to change those APIs
consistentlywith what<br /> is added on the parsing side.<br /></div><div class="gmail_extra">It could make more sense
tohave such a set of functions created as a<br /></div><div class="gmail_extra">separate project.<br /><br /></div><div
class="gmail_extra">My 2c.<br /></div><div class="gmail_extra">-- <br />Michael<br /></div></div>
