Re: revised sample SRF C function; proposed SRF API

From: Joe Conway <mail(at)joeconway(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: revised sample SRF C function; proposed SRF API
Date: 2002-05-27 21:56:07
Message-ID: 3CF2AB77.2040103@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Peter Eisentraut wrote:
> We need a function like this in the main line. The "show all" variety
> isn't top priority, but we need something that gets you the "show" result
> as a query output. The original idea was to make SHOW return a query
> result directly, but a function is fine with me too.
>

Originally I wrote this as "showvars(varname)" and accepted 'all' in a
similar fashion to SHOW ALL. But it seemed redundant since you can still do:

test=# select * from showvars() where varname = 'wal_sync_method';
varname | varval
-----------------+-----------
wal_sync_method | fdatasync
(1 row)

but you can also do:

test=# select * from showvars() where varname like 'show%';
varname | varval
---------------------+--------
show_executor_stats | off
show_parser_stats | off
show_planner_stats | off
show_query_stats | off
show_source_port | off
(5 rows)

which also seemed useful.

I was thinking that if we wanted to replace SHOW X with this, it could
be done in the parser by rewriting it as "SELECT * FROM showvars() WHERE
varname = 'X'", or for SHOW ALL just "SELECT * FROM showvars()".

In any case, I'll fit the showvars() function into the backend and
submit a patch.

Thanks,

Joe

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2002-05-27 22:11:38 Re: SRF rescan testing
Previous Message Tom Lane 2002-05-27 21:54:08 Re: strange update problem with 7.2.1

Browse pgsql-patches by date

  From Date Subject
Next Message Bear Giles 2002-05-27 21:58:22 Re: SSL (patch 3)
Previous Message Bear Giles 2002-05-27 21:47:59 Re: SSL (patch 2)