Re: [PATCHES] WIP: executor_hook for pg_stat_statements - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCHES] WIP: executor_hook for pg_stat_statements
Date
Msg-id 10029.1215442263@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCHES] WIP: executor_hook for pg_stat_statements  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: [PATCHES] WIP: executor_hook for pg_stat_statements  (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
Re: [PATCHES] WIP: executor_hook for pg_stat_statements  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
Simon Riggs <simon@2ndquadrant.com> writes:
> On Mon, 2008-07-07 at 11:03 +0900, ITAGAKI Takahiro wrote:
>> One issue is "tag" field. The type is now uint32. It's enough in my plugin,
>> but if some people need to add more complex structures in PlannedStmt,
>> Node type would be better rather than uint32. Which is better?

> I was imagining that tag was just an index to another data structure,
> but probably better if its a pointer.

I don't want the tag there at all, much less converted to a pointer.
What would the semantics be of copying the node, and why?

Please justify why you must have this and can't do what you want some
other way.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Zdenek Kotala
Date:
Subject: Re: PATCH: CITEXT 2.0 v2
Next
From: Bernd Helmle
Date:
Subject: Re: Schema-qualified statements in pg_dump output