Thread: pgstattuple change using SRF

pgstattuple change using SRF

From
Tatsuo Ishii
Date:
I'm going to change contrib/pgstattuple so that it returns a tuple
rather than a NOTICE using new SRF interface. I believe this way is
much more convenient for users. Any objection?
--
Tatsuo Ishii


Re: pgstattuple change using SRF

From
Tom Lane
Date:
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> I'm going to change contrib/pgstattuple so that it returns a tuple
> rather than a NOTICE using new SRF interface. I believe this way is
> much more convenient for users. Any objection?

Sure.  I like the way Joe did show_all() better than the way Neil
did lock_status() --- I'm in the middle of getting rid of zero
type OIDs throughout the system, and so I'm not happy with anything
that re-introduces them, even if it's only transient during initdb.
Other than that minor point, go for it...
        regards, tom lane


Re: pgstattuple change using SRF

From
Tatsuo Ishii
Date:
> Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> > I'm going to change contrib/pgstattuple so that it returns a tuple
> > rather than a NOTICE using new SRF interface. I believe this way is
> > much more convenient for users. Any objection?
> 
> Sure.  I like the way Joe did show_all() better than the way Neil
> did lock_status() --- I'm in the middle of getting rid of zero
> type OIDs throughout the system, and so I'm not happy with anything
> that re-introduces them, even if it's only transient during initdb.
> Other than that minor point, go for it...

I think pgstattuple() never uses OPAQUE...
--
Tatsuo Ishii


Re: pgstattuple change using SRF

From
Tatsuo Ishii
Date:
> I'm going to change contrib/pgstattuple so that it returns a tuple
> rather than a NOTICE using new SRF interface. I believe this way is
> much more convenient for users. Any objection?

I have committed above changes.
--
Tatsuo Ishii