I wrote:
> I had an idea about that. I've not tested this, but I think it would be
> a trivial matter of adding a coalesce() call to make the query act like
> the type name for a not-present argument is an empty string, rather than
> NULL which is what it gets right now. Then you could do what I
I wrote:
> Greg Sabino Mullane writes:
>> * There seems to be no way (?) to limit the functions returned if they
>> share a common root. The previous incantation allowed you to pull out
>> foo(int) from foo(int, bigint). This was a big motivation for writing this
>> patch.
> Hmm, are you trying t
I wrote:
> Greg Sabino Mullane writes:
>> * SQL error on \df foo a..b as well as one on \df foo (bigint bigint)
> The first one seems to be a bug, will look.
Argh, silly typo (and I'd failed to test the schema-qualified-name case).
While I was thinking about use-cases for this, I realized that
Greg Sabino Mullane writes:
> I like the wildcard aspect, but I have a few issues with the patch:
> * It doesn't respect some common abbreviations that work elsewhere (e.g.
> CREATE FUNCTION). So while "int4" works, "int" does not. Nor does "float",
> which thus requires the mandatory-double-quot
I like the wildcard aspect, but I have a few issues with the patch:
* It doesn't respect some common abbreviations that work elsewhere (e.g.
CREATE FUNCTION). So while "int4" works, "int" does not. Nor does "float",
which thus requires the mandatory-double-quoted "double precision"
* Adding comma
Greg Sabino Mullane writes:
> [ v6-psql-df-pick-function-by-type.patch ]
I looked this over. I like the idea a lot, but not much of anything
about the implementation. I think the additional arguments should be
matched to the function types using the same rules as for \dT. That
allows patterns
On 1/19/21 11:58 AM, Greg Sabino Mullane wrote:
Ha ha ha, my bad, I am not sure why I left those out. Here is a new
patch with int2, int4, and int8. Thanks for the email.
Ian, does the new patch look good to you?
Also, not sure why the target version for this patch is stable so I have
updated
Ha ha ha, my bad, I am not sure why I left those out. Here is a new patch
with int2, int4, and int8. Thanks for the email.
Cheers,
Greg
v6-psql-df-pick-function-by-type.patch
Description: Binary data
2021年1月15日(金) 1:46 Greg Sabino Mullane :
> Thanks for the feedback: new version v5 (attached) has int8, plus the
> suggested code formatting.
>
> Cheers,
> Greg
>
Thanks for the update.
In my preceding mail I meant we should add int2, int4 and int8 for
completeness
(apologies, I was a bit unclea
Thanks for the feedback: new version v5 (attached) has int8, plus the
suggested code formatting.
Cheers,
Greg
v5-psql-df-pick-function-by-type.patch
Description: Binary data
Hi
I tried this patch out last year but was overrolled by Other Stuff before I got
around to providing any feedback, and was reminded of it just now when I was
trying to execute "\df somefunction text int" or similar, which had me
confused until I remembered it's not a feature yet, so it would
cer
On Sat, Jan 2, 2021 at 1:56 AM Thomas Munro wrote:
> ...
> It looks like there is a collation dependency here that causes the
> test to fail on some systems:
>
Thanks for pointing that out. I tweaked the function definitions to
hopefully sidestep the ordering issue - attached is v4.
Cheers,
Gre
On Thu, Dec 31, 2020 at 7:01 AM Greg Sabino Mullane wrote:
> Attached is the latest patch against HEAD - basically fixes a few typos.
Hi Greg,
It looks like there is a collation dependency here that causes the
test to fail on some systems:
=== ./src/test/regress/regression.diffs ===
diff -U3 /t
Attached is the latest patch against HEAD - basically fixes a few typos.
Cheers,
Greg
v3-psql-df-pick-function-by-type.patch
Description: Binary data
On Sun, Nov 1, 2020 at 12:05 PM David Christensen wrote:
>
> I can’t speak for the specific patch, but tab completion of proc args for
> \df, \ef and friends has long been a desired feature of mine, particularly
> when you are dealing with functions with huge numbers of arguments and the
> same n
Thanks for looking this over!
> some Abbreviations of common types are not added to the
> type_abbreviations[] Such as:
>
> Int8=> bigint
>
I wasn't aiming to provide a canonical list, as I personally have never
seen anyone use int8 instead of bigint when (for example) creating a
Hi
(sorry forget to cc the hacklist)
> Improve psql \df to choose functions by their arguments
I think this is useful.
I found some comments in the patch.
1.
> * Abbreviations of common types is permitted (because who really likes
> to type out "character varying"?), so the above could also b
> * Removed the tab-complete bit, it was too fragile and unhelpful
I can’t speak for the specific patch, but tab completion of proc args for \df,
\ef and friends has long been a desired feature of mine, particularly when you
are dealing with functions with huge numbers of arguments and the sam
Thanks for the feedback, attached is version two of the patch. Major
changes:
* Use booleans not generic "int x"
* Build a quick list of abbreviations at the top of the function
* Add array mapping for all types
* Removed the tab-complete bit, it was too fragile and unhelpful
Cheers,
Greg
diff --
Thank you for looking this over.
> This isn't working for arrays:
> ...
> postgres=# \df aa aa int[]
>
Arrays should work as expected, I think you have one too many "aa" in there?
> I think it should use the same syntax as \sf and \ef, which require
> parenthesis
> and commas, not spaces.
>
H
On Thu, Oct 15, 2020 at 01:21:06PM -0400, Greg Sabino Mullane wrote:
> Improve psql \df to choose functions by their arguments
I think this is a good idea.
This isn't working for arrays:
postgres=# \df aa
public | aa | integer | integer, integer| func
public | aa | int
21 matches
Mail list logo
