Thread: Have psql display names and OUT/INOUT in \df output
Folks, This patch makes psql's \df display functions with the names of parameters and OUT/INOUT if appropriate. Should there be a regression test for this? A doc patch? Cheers, D -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
Attachment
David Fetter wrote: > Folks, > > This patch makes psql's \df display functions with the names of > parameters and OUT/INOUT if appropriate. Should there be a regression > test for this? A doc patch? > > Regression tests are for server functionality, generally. Possibly docs should be patched. cheers andrew
On Sat, Jul 15, 2006 at 04:42:50PM -0700, David Fetter wrote: > Folks, > > This patch makes psql's \df display functions with the names of > parameters and OUT/INOUT if appropriate. Should there be a > regression test for this? A doc patch? As this doesn't change any documented behavior, it doesn't look like there is space for a doc patch. Anyhow, please find enclosed the context-style diff. Sorry about the mix-up earlier :) Cheers, D -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
Attachment
On Sat, 2006-07-15 at 23:16 -0700, David Fetter wrote:
> Anyhow, please find enclosed the context-style diff.
How carefully did you test this?
postgres=# \df abc
List of functions
Schema | Name | Result data type | Argument data types
--------+------+------------------+---------------------
public | abc | integer | a integer,b integer
(1 row)
(The argument list should be separated by both a comma and whitespace.)
postgres=# create or replace function xyz(inout a int, inout int)
returns record as 'select (1, 2);' language sql;
CREATE FUNCTION
postgres=# \df xyz
List of functions
Schema | Name | Result data type | Argument data types
--------+------+------------------+----------------------------------
public | xyz | record | INOUT a integer, INOUT integer
(1 row)
(Spurious whitespace for the unnamed INOUT parameter.)
You need to schema-qualify references to builtin functions, to avoid
accidentally using functions of the same name that appear earlier in the
user's search path. (As a general rule, look at the surrounding code
carefully before you modify it.)
It would be nice to be consistent about SQL style, at least within a
single query (e.g. don't separate function arguments with whitespace in
some places but not others).
-Neil
On Sun, Jul 16, 2006 at 12:21:12AM -0700, Neil Conway wrote: > On Sat, 2006-07-15 at 23:16 -0700, David Fetter wrote: > > Anyhow, please find enclosed the context-style diff. > > How carefully did you test this? Not enough. Here's the latest. > postgres=# \df abc > List of functions > Schema | Name | Result data type | Argument data types > --------+------+------------------+--------------------- > public | abc | integer | a integer,b integer > (1 row) > > (The argument list should be separated by both a comma and whitespace.) > > postgres=# create or replace function xyz(inout a int, inout int) > returns record as 'select (1, 2);' language sql; > CREATE FUNCTION > postgres=# \df xyz > List of functions > Schema | Name | Result data type | Argument data types > --------+------+------------------+---------------------------------- > public | xyz | record | INOUT a integer, INOUT integer > (1 row) These are now fixed. > (Spurious whitespace for the unnamed INOUT parameter.) > > You need to schema-qualify references to builtin functions, to avoid > accidentally using functions of the same name that appear earlier in > the user's search path. I don't understand what you mean here. The schema name comes with both versions of \df, just as it did before. Cheers, D -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
Attachment
On Sun, 2006-07-16 at 01:00 -0700, David Fetter wrote: > On Sun, Jul 16, 2006 at 12:21:12AM -0700, Neil Conway wrote: > > You need to schema-qualify references to builtin functions, to avoid > > accidentally using functions of the same name that appear earlier in > > the user's search path. > > I don't understand what you mean here. For example, you shouldn't be using "generate_series" in the SQL query: if the user has a function of the same name earlier in their search path, psql will invoke the wrong function. Instead, you should call "pg_catalog.generate_series", as psql was careful to do prior to the patch. -Neil
On Sun, Jul 16, 2006 at 05:16:58AM -0700, Neil Conway wrote: > On Sun, 2006-07-16 at 01:00 -0700, David Fetter wrote: > > On Sun, Jul 16, 2006 at 12:21:12AM -0700, Neil Conway wrote: > > > You need to schema-qualify references to builtin functions, to > > > avoid accidentally using functions of the same name that appear > > > earlier in the user's search path. > > > > I don't understand what you mean here. > > For example, you shouldn't be using "generate_series" in the SQL > query: if the user has a function of the same name earlier in their > search path, psql will invoke the wrong function. Instead, you > should call "pg_catalog.generate_series", as psql was careful to do > prior to the patch. Thanks for clarifying this. Patch attached. Cheers, D -- David Fetter <david@fetter.org> http://fetter.org/ phone: +1 415 235 3778 AIM: dfetter666 Skype: davidfetter Remember to vote!
Attachment
On Sun, 2006-07-16 at 07:18 -0700, David Fetter wrote: > Thanks for clarifying this. Patch attached. Applied, with one more fix: format_type's second argument should be NULL if it is not otherwise known. Thanks for the patch. (Speaking of which, there is probably room for a one-parameter version of format_type() that just calls the normal version with a NULL for the second parameter...) -Neil