But half of the postgresql "functions" are in the grammar anyway -
they're not even listed.
Should we look at adding stub functions into pg_proc for \df display
somehow?
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
On Fri, Apr 01, 2005 at 12:08:54PM -, Greg Sabino Mullane wrote:
> Quoting Tom Lane:
> > I thought the "S" suggestion was much better than this.
> >
> > Personally I am not unhappy with the existing behavior, because (unlike
> > Greg I guess) I use \df and \do to look at system definitions all
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
> Uh, who exactly agreed to that? I know when I do \df it's generally
> to check out built-in functions not my own. I don't see this as an
> improvement.
Quoting Tom Lane:
> I thought the "S" suggestion was much better than this.
>
But half of the postgresql "functions" are in the grammar anyway -
they're not even listed.
Should we look at adding stub functions into pg_proc for \df display
somehow?
I'm not suggesting that at all. I was just pointing out that \df isn't
a useful view of 'what functions does postgresql have t
On Fri, Apr 01, 2005 at 12:59:43PM +0800, Christopher Kings-Lynne wrote:
>
> I only ever use \df to look at my own functions...
>
> I'd prefer if no system functions were listed :)
You can use, for example, "\df public." to see only those functions
in the public schema. That's what I do when I
On Fri, Apr 01, 2005 at 12:08:21AM -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> >
> > What makes you think you can't call 'em from SQL?
> >
> > regression=# select int4in('345');
> > int4in
> >
> > 345
> > (1 row)
>
> Yes, I guess I mean does it make sense to call them from SQL
Christopher Kings-Lynne wrote:
> > I use df to see what functions are available. I want to see them all.
>
> But half of the postgresql "functions" are in the grammar anyway -
> they're not even listed.
Should we look at adding stub functions into pg_proc for \df display
somehow?
--
Bruce Mo
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> What makes you think you can't call 'em from SQL?
>
> > Yes, I guess I mean does it make sense to call them from SQL? Their
> > purpose is for internal use, no?
>
> People have actually used them for purposes of cross-type convers
I use df to see what functions are available. I want to see them all.
But half of the postgresql "functions" are in the grammar anyway -
they're not even listed.
Chris
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an
I use df to see what functions are available. I want to see them all.
--elein
On Fri, Apr 01, 2005 at 12:59:43PM +0800, Christopher Kings-Lynne wrote:
> >Uh, who exactly agreed to that? I know when I do \df it's generally
> >to check out built-in functions not my own. I don't see this as an
> >
Bruce Momjian writes:
> Tom Lane wrote:
>> What makes you think you can't call 'em from SQL?
> Yes, I guess I mean does it make sense to call them from SQL? Their
> purpose is for internal use, no?
People have actually used them for purposes of cross-type conversion
where there's I/O compatibil
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> We could fix it by changing <> to IS DISTINCT FROM ... but I've never
> >> been very happy with the idea that \df tries to suppress I/O functions
> >> anyway. How do you feel about removing the cstring test altogether?
>
> > I like
Bruce Momjian writes:
> Tom Lane wrote:
>> We could fix it by changing <> to IS DISTINCT FROM ... but I've never
>> been very happy with the idea that \df tries to suppress I/O functions
>> anyway. How do you feel about removing the cstring test altogether?
> I like the cstring test. I don't th
Uh, who exactly agreed to that? I know when I do \df it's generally
to check out built-in functions not my own. I don't see this as an
improvement.
I only ever use \df to look at my own functions...
I'd prefer if no system functions were listed :)
Chris
---(end of broadcas
Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > The problem appears to be that proargtypes[0] is now NULL instead
> > of 0. Here's a simplified version of the \df query:
>
> > SELECT proname
> > FROM pg_catalog.pg_proc p
> > WHERE p.proargtypes[0] <> 'pg_catalog.cstring'::pg_
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> This could work out well with my upcoming patch to have \df only
> show non-system functions. Since the user will in the future have
> to explicitly call \dfS to see the system functions, 60 extra
> out of 1700 should not matter too much.
Uh, who
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> Wouldn't bother me -- I'd rather see what's there and make the
> "uninteresting" call myself, if that's the only reason for not
> showing the I/O functions. It's not like they'd overwhelm the
> output.
This could work out well with my upcoming pa
On Thu, Mar 31, 2005 at 01:06:39AM -0500, Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > The problem appears to be that proargtypes[0] is now NULL instead
> > of 0. Here's a simplified version of the \df query:
>
> > SELECT proname
> > FROM pg_catalog.pg_proc p
> > WHERE p.p
Michael Fuhr <[EMAIL PROTECTED]> writes:
> The problem appears to be that proargtypes[0] is now NULL instead
> of 0. Here's a simplified version of the \df query:
> SELECT proname
> FROM pg_catalog.pg_proc p
> WHERE p.proargtypes[0] <> 'pg_catalog.cstring'::pg_catalog.regtype
> AND p.pr
19 matches
Mail list logo
