Attached patch applied, including documentation updates; I think this
is the best we are going to do to balance usability and consistency. I
have removed this as an open 8.4 item.
With this change \dfS and \df * do the same thing; I assume we don't
want to remove the 'S' modifier and tell peop
Robert Treat wrote:
> Actually I find the inconsistency to hurt usability, which is typically what
> you get with inconsistent interfaces.
>
> I'm not certain, but I think I would be happier if we did:
>
> \d*user space objects
> \d*S include system objects
>
> For those that want system
Robert Treat wrote:
> On Monday 30 March 2009 10:52:47 Bruce Momjian wrote:
> > Robert Haas wrote:
> > > On Mon, Mar 30, 2009 at 10:13 AM, Bruce Momjian wrote:
> > > > Maybe the best we are going to do is to have any pattern supplied to
> > > > \d* assume 'S' (include system objects). ?I actually
On Monday 30 March 2009 10:52:47 Bruce Momjian wrote:
> Robert Haas wrote:
> > On Mon, Mar 30, 2009 at 10:13 AM, Bruce Momjian wrote:
> > > Maybe the best we are going to do is to have any pattern supplied to
> > > \d* assume 'S' (include system objects). ?I actually have a patch that
> > > does t
On Mon, Mar 30, 2009 at 09:59:41PM +0200, Dimitri Fontaine wrote:
> Hi,
>
> Le 30 mars 09 à 16:52, Bruce Momjian a écrit :
>> I think the big question is whether the inconsistency (pattern implies
>> 'S') is worth accepting for greater usability.
>
>
> My answer is yes, please, definitely, go for i
Hi,
Le 30 mars 09 à 16:52, Bruce Momjian a écrit :
I think the big question is whether the inconsistency (pattern implies
'S') is worth accepting for greater usability.
My answer is yes, please, definitely, go for it.
We don't need idiot-proof easy to remember semantics, we need useful
ones
On Mon, Mar 30, 2009 at 10:52 AM, Bruce Momjian wrote:
> Robert Haas wrote:
>> On Mon, Mar 30, 2009 at 10:13 AM, Bruce Momjian wrote:
>> > Maybe the best we are going to do is to have any pattern supplied to \d*
>> > assume 'S' (include system objects). ?I actually have a patch that does
>> > tha
Robert Haas wrote:
> On Mon, Mar 30, 2009 at 10:13 AM, Bruce Momjian wrote:
> > Maybe the best we are going to do is to have any pattern supplied to \d*
> > assume 'S' (include system objects). ?I actually have a patch that does
> > that, attached. (It is from January so might need adjustment.)
>
On Mon, Mar 30, 2009 at 10:29 AM, Tom Lane wrote:
> Robert Haas writes:
>> That still has the problem that "\df a*" is horribly inconsistent with
>> "\df". It might be reasonable to assume that if a name without
>> wildcards is given to any \d command, it should display whatever
>> object it fin
Maybe the best we are going to do is to have any pattern supplied to \d*
assume 'S' (include system objects). I actually have a patch that does
that, attached. (It is from January so might need adjustment.)
---
Robert Haas
On Mon, Mar 30, 2009 at 10:13 AM, Bruce Momjian wrote:
> Maybe the best we are going to do is to have any pattern supplied to \d*
> assume 'S' (include system objects). I actually have a patch that does
> that, attached. (It is from January so might need adjustment.)
That still has the problem t
Robert Haas writes:
> That still has the problem that "\df a*" is horribly inconsistent with
> "\df". It might be reasonable to assume that if a name without
> wildcards is given to any \d command, it should display whatever
> object it finds, user or system - but I can't see doing it for any
> w
On Sun, Mar 29, 2009 at 1:32 PM, Tom Lane wrote:
> Now I *have* a user function named sin(), it's not getting called
> (which might surprise me if I didn't know there was a conflicting
> system function) and \df doesn't show me either one.
>
> I actually was expecting the above example to show me
Tom Lane wrote:
> I actually was expecting the above example to show me the user function,
> which I was then going to rant about being a lie. But the actual
> behavior is even worse than that.
>
> There is not anything that is not broken about HEAD's behavior,
> and the sooner we admit that the
Robert Haas writes:
> I think you should reconsider your non-buying of that argument. That
> would be really, really annoying for me. Most of the time I want to
> look at a user object. But every now and then I want to look at a
> system object.
I still think that this argument is fundamentall
On Sat, Mar 28, 2009 at 4:25 PM, Bruce Momjian wrote:
> Euler Taveira de Oliveira wrote:
>> Bruce Momjian escreveu:
>> > The psql system object display issue has not been completely resolved
>> > for 8.4; see 8.4 open items:
>> >
>> > http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items#
On Sat, Mar 28, 2009 at 1:25 AM, Euler Taveira de Oliveira
wrote:
> Bruce Momjian escreveu:
>> The psql system object display issue has not been completely resolved
>> for 8.4; see 8.4 open items:
>>
>> http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items#Changes
>>
>> So what is the p
Euler Taveira de Oliveira wrote:
> Bruce Momjian escreveu:
> > The psql system object display issue has not been completely resolved
> > for 8.4; see 8.4 open items:
> >
> > http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items#Changes
> >
> > So what is the proposal? Have U/S/A flags f
Bruce Momjian escreveu:
> The psql system object display issue has not been completely resolved
> for 8.4; see 8.4 open items:
>
> http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items#Changes
>
> So what is the proposal? Have U/S/A flags for all commands and have
> different system d
The psql system object display issue has not been completely resolved
for 8.4; see 8.4 open items:
http://wiki.postgresql.org/wiki/PostgreSQL_8.4_Open_Items#Changes
So what is the proposal? Have U/S/A flags for all commands and have
different system display default for each command?
I
20 matches
Mail list logo
