"Tom Lane" <[EMAIL PROTECTED]> writes:
> "Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
>>> \df Lists all user functions
>>> \df [pattern] Lists both system and user functions matching [pattern]
>>> \df * Lists all system and user functions
>
>> I don't like this for two reasons: the items retu
The patch author has been given feedback, so this has been saved for the
next commit-fest:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Greg Sabino Mullane wrote:
[ There is text before PGP section. ]
>
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
> > One question: should \df really list *all* nonsystem functions? Or
> > just the ones that are visible in your search path? I'd be
> > inclined to say the second.
> >
> >
> >
>
>
> +1 (although maybe that discussion belongs on -hackers, or eve
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/04/2008, Greg Sabino Mullane wrote:
> > \df Lists all user functions
> > \df [pattern] Lists both system and user functions matching [pattern]
> > \df * Lists all system and user functions
>
> I don't like this for two reasons: the items retu
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
>> \df Lists all user functions
>> \df [pattern] Lists both system and user functions matching [pattern]
>> \df * Lists all system and user functions
> I don't like this for two reasons: the items returned changes based on
> the existence of args,
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> \df Lists all user functions
> \df [pattern] Lists both system and user functions matching [pattern]
> \df * Lists all system and user functions
I don't like this for two reasons: the items returned changes based on
the existence of args, rat
"Tom Lane" <[EMAIL PROTECTED]> writes:
> "Brendan Jurd" <[EMAIL PROTECTED]> writes:
>> If I read Greg's latter proposal correctly, he was suggesting
>
>> \df Lists all user functions
>> \df [pattern] Lists both system and user functions matching [pattern]
>> \df * Lists all system and user functio
Tom Lane wrote:
One question: should \df really list *all* nonsystem functions? Or just
the ones that are visible in your search path? I'd be inclined to say
the second.
+1 (although maybe that discussion belongs on -hackers, or even -general)
cheers
andrew
--
Sent via pgsql-patch
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> If I read Greg's latter proposal correctly, he was suggesting
> \df Lists all user functions
> \df [pattern] Lists both system and user functions matching [pattern]
> \df * Lists all system and user functions
Hmm, I must've misread it, because I didn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/04/2008, Tom Lane wrote:
> David Fetter writes:
> > When we have a bad default--and I'd argue that for anyone not
> > developing PostgreSQL itself, showing system functions is a bad
> > default--we should change it to something sane.
>
> I d
David Fetter <[EMAIL PROTECTED]> writes:
> When we have a bad default--and I'd argue that for anyone not
> developing PostgreSQL itself, showing system functions is a bad
> default--we should change it to something sane.
I disagree with your parenthetical argument here, mainly on the strength
of G
On Tue, Apr 01, 2008 at 12:58:44AM -0400, Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> >>> One --perhaps nice, perhaps not-- property of this is that if
> >>> you defined a function named "rtrim" and then did "\df rtrim" it
> >>> would show you _both_ the system and user function a
Gregory Stark <[EMAIL PROTECTED]> writes:
>>> One --perhaps nice, perhaps not-- property of this is that if you defined a
>>> function named "rtrim" and then did "\df rtrim" it would show you _both_ the
>>> system and user function and make it easier to see the conflict. Whereas the
>>> other behav
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> One --perhaps nice, perhaps not-- property of this is that if you defined a
>> function named "rtrim" and then did "\df rtrim" it would show you _both_ the
>> system and user function and make it easier to see th
Tom Lane wrote:
> BTW, should we remove the special hack that discriminates against
> showing I/O functions (or really anything that touches cstring) in \df?
> ISTM that was mostly there to reduce clutter, and this proposal solves
> that problem more neatly. I know I've cursed that behavior under
Gregory Stark <[EMAIL PROTECTED]> writes:
> One --perhaps nice, perhaps not-- property of this is that if you defined a
> function named "rtrim" and then did "\df rtrim" it would show you _both_ the
> system and user function and make it easier to see the conflict. Whereas the
> other behaviour I p
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> It might be cute to see if the pattern matches any user functions and if not
>> try again with system functions. So you would still get results if you did
>> "\df rtrim" for example.
>
> Interesting idea. IIUC,
On 01/04/2008, Tom Lane <[EMAIL PROTECTED]> wrote:
> ... That means
> there'd be no way to replicate the all-functions-of-both-types behavior
> that has been the default in every prior release.
> \dfS-> sys functions only
> \dfU-> user functions only
> \dfSU ->
Gregory Stark <[EMAIL PROTECTED]> writes:
> It might be cute to see if the pattern matches any user functions and if not
> try again with system functions. So you would still get results if you did
> "\df rtrim" for example.
Interesting idea. IIUC, \df would give you either all user functions
*o
On 31/03/2008, Gregory Stark <[EMAIL PROTECTED]> wrote:
> It might be cute to see if the pattern matches any user functions and if not
> try again with system functions. So you would still get results if you did
> "\df rtrim" for example.
>
Nice idea. +1 for this behaviour.
Cheers,
BJ
--
Se
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Hmm. Personally, most of my uses of \df are for the purpose of looking
> for built-in functions, and so this'd be a step backwards for my usage.
> Likewise for operators. Maybe I'm in the minority or maybe not.
> The only one of these things for which the
Greg Sabino Mullane <[EMAIL PROTECTED]> writes:
> Attached is an updated version of my psql patch that makes the \d
> backslash commands perform in an intuitive, consistent way.
> Specifically, the following objects will be treated as first class
> citizens (as tables and indexes currently are) by
Greg Sabino Mullane wrote:
Attached is an updated version of my psql patch that makes the \d
backslash commands perform in an intuitive, consistent way.
Specifically, the following objects will be treated as first class
citizens (as tables and indexes currently are) by showing all the
non-system
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Greg Sabino Mullane wrote:
> Attached is an updated version of my psql patch that makes the \d
> backslash commands p
24 matches
Mail list logo
