Stephen Frost wrote:
-- Start of PGP signed section.
> Bruce, et al,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > \dg [PATTERN]list roles (groups)
> > \du [PATTERN]list roles (users)
>
> Seeing this list reminded me of a pet-peeve.. \du and \dg actually show
>
Stephen Frost writes:
> Seeing this list reminded me of a pet-peeve.. \du and \dg actually show
> the same info, that's fine, but neither of them show the rolcanlogin
> value.
+1 for fixing that.
>> \dp [PATTERN]list table, view, and sequence access privileges
> erp, I don't think I c
Bruce, et al,
* Bruce Momjian (br...@momjian.us) wrote:
> \dg [PATTERN]list roles (groups)
> \du [PATTERN]list roles (users)
Seeing this list reminded me of a pet-peeve.. \du and \dg actually show
the same info, that's fine, but neither of them show the rolcanlo
* Robert Haas (robertmh...@gmail.com) wrote:
> > Here are the items I think are best to default to user-only:
> [...]
> > Here are the ones that should include system objects by default:
[...]
> So maybe we should provide U, S, and A modifiers for every type of
> object (user, system, all). That d
> Here are the items I think are best to default to user-only:
[...]
> Here are the ones that should include system objects by default:
Well, at a minimum, I think it's important for any type of object to
have an easy way to exclude system objects, because "show me all of
the stuff that didn't com
Alvaro Herrera wrote:
> Bruce Momjian escribi?:
> > Alvaro Herrera wrote:
> > > Bruce Momjian escribi?:
> > >
> > > > Well, to do this you are going to need 'U' and 'S' modifiers, and then
> > > > we have to decide how \df is supposed to behave.
> > >
> > > I think we should have first decided ho
Bruce Momjian escribió:
> Alvaro Herrera wrote:
> > Bruce Momjian escribi?:
> >
> > > Well, to do this you are going to need 'U' and 'S' modifiers, and then
> > > we have to decide how \df is supposed to behave.
> >
> > I think we should have first decided how it was supposed to behave, and
> > l
Alvaro Herrera wrote:
> Bruce Momjian escribi?:
>
> > Well, to do this you are going to need 'U' and 'S' modifiers, and then
> > we have to decide how \df is supposed to behave.
>
> I think we should have first decided how it was supposed to behave, and
> later applied any patches.
Well, there w
Bruce Momjian escribió:
> Well, to do this you are going to need 'U' and 'S' modifiers, and then
> we have to decide how \df is supposed to behave.
I think we should have first decided how it was supposed to behave, and
later applied any patches.
--
Alvaro Herrera
Alvaro Herrera wrote:
> Bruce Momjian escribi?:
>
> > But frankly, with a very complex backslash API that is already
> > overloaded, I figured having a consistent 'S' to include system objects
> > was the best we are going to be able to do. Once this is out in the
> > field we might get new ideas
Bruce Momjian escribió:
> But frankly, with a very complex backslash API that is already
> overloaded, I figured having a consistent 'S' to include system objects
> was the best we are going to be able to do. Once this is out in the
> field we might get new ideas.
I don't buy this argument. If
Peter Eisentraut wrote:
> On Friday 16 January 2009 04:09:11 Robert Haas wrote:
> > I really wonder what is so terrible about the behavrior as implemented
> > in CVS HEAD. ?AFAICS, no one except maybe Tom has really specified WHY
> > they don't like it, just that they don't like it. ?I'm not sure
>
On Friday 16 January 2009 04:09:11 Robert Haas wrote:
> I really wonder what is so terrible about the behavrior as implemented
> in CVS HEAD. AFAICS, no one except maybe Tom has really specified WHY
> they don't like it, just that they don't like it. I'm not sure
> whether that's because (1) it's
Stephen Frost wrote:
> Alvaro,
>
> * Alvaro Herrera (alvhe...@commandprompt.com) wrote:
>> Tom Lane escribió:
>>> If you have an idle evening you might want to peruse all the past
>>> threads about developing better support for modules.
>> All the useful material in this area is linked to on the T
On Thu, 2009-01-15 at 20:19 -0800, Josh Berkus wrote:
> Tom,
>
> > Also (3) you are not actually going to use this as much as you think
> > you are, so saving a shift keypress is not the be-all and end-all.
>
> Clearly you've never had to troubleshoot a client's database which has
> over 400 fun
Josh Berkus wrote:
Tom,
Also (3) you are not actually going to use this as much as you think
you are, so saving a shift keypress is not the be-all and end-all.
Clearly you've never had to troubleshoot a client's database which has
over 400 functions they've never completely documented.
Oh
Tom,
Also (3) you are not actually going to use this as much as you think
you are, so saving a shift keypress is not the be-all and end-all.
Clearly you've never had to troubleshoot a client's database which has
over 400 functions they've never completely documented.
--Josh
--
Sent via pg
Alvaro,
* Alvaro Herrera (alvhe...@commandprompt.com) wrote:
> Tom Lane escribió:
> > If you have an idle evening you might want to peruse all the past
> > threads about developing better support for modules.
>
> All the useful material in this area is linked to on the TODO list.
Thanks for the
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> If you have an idle evening you might want to peruse all the past
> threads about developing better support for modules. This is clearly
> an area where we need to improve, and it's also clear that no quick
> hack is going to make it significantly better (i
Tom Lane escribió:
> Stephen Frost writes:
> > As I mentioned in my other email, this is mainly for PostGIS, but it can
> > certainly apply to other modules. Is this what we would recommend as an
> > approach for these kinds of modules? I feel like that would give
> > -hackers, or perhaps the Po
Stephen Frost writes:
> As I mentioned in my other email, this is mainly for PostGIS, but it can
> certainly apply to other modules. Is this what we would recommend as an
> approach for these kinds of modules? I feel like that would give
> -hackers, or perhaps the PostGIS people, some heartburn,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Read the documentation for search_path: if pg_catalog isn't explicitly
> mentioned, we add it implicitly. This is mainly because it would be
> contrary to SQL spec (and pretty useless to boot) to not recognize the
> standard functions and operators. But be
Stephen Frost writes:
> Regardless of what I reset my search_path to, I'm going to have access
> to abstime. Is there something else special about it besides being
> a 'system function' and being in pg_catalog to make it always available
> regardless of my search_path?
Read the documentation for
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Josh Berkus writes:
> >> But I may be trying to push water up a hill, so, I can live with
> >> adding \dfU and keeping \df as-was.
>
> > BTW, why the capital? \dfu is *considerably* easier to type than \dfU.
>
> Because (1) its counterpart S is capitaliz
Josh,
* Josh Berkus (j...@agliodbs.com) wrote:
>> On a seperate (kind of) note, I'd really like to be able to say "I want
>> this function visible everywhere" like a system function. public really
>> doesn't fit this bill very well, in my experience.
>
> We're *so* not going there. If you really
Josh Berkus writes:
>> But I may be trying to push water up a hill, so, I can live with
>> adding \dfU and keeping \df as-was.
> BTW, why the capital? \dfu is *considerably* easier to type than \dfU.
Because (1) its counterpart S is capitalized by historical tradition,
and (2) we are going to a
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > On a seperate (kind of) note, I'd really like to be able to say "I want
> > this function visible everywhere" like a system function.
>
> Huh? System functions don't have that property either.
Perhaps I'm missing something, or i
* Josh Berkus (j...@agliodbs.com) wrote:
>> But I may be trying to push water up a hill, so, I can live with
>> adding \dfU and keeping \df as-was.
>
> BTW, why the capital? \dfu is *considerably* easier to type than \dfU.
I havn't got much of a preference for \dfu vs. \dfU. Either works for
me.
All,
But I may be trying to push water up a hill, so, I can live with
adding \dfU and keeping \df as-was.
BTW, why the capital? \dfu is *considerably* easier to type than \dfU.
\JosH
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
On Thu, Jan 15, 2009 at 8:25 PM, Tom Lane wrote:
> Stephen Frost writes:
>> gah, I find that to be terrible. If we wanted to compromise, I'd
>> rather have \df do what it does today, to keep backwards-compat and
>> not confuse users, and \dfU to do what I want 99% of the time.
>
> This seems to
On Thu, 2009-01-15 at 20:25 -0500, Tom Lane wrote:
> Stephen Frost writes:
> > gah, I find that to be terrible. If we wanted to compromise, I'd
> > rather have \df do what it does today, to keep backwards-compat and
> > not confuse users, and \dfU to do what I want 99% of the time.
>
> This seem
Stephen Frost writes:
> gah, I find that to be terrible. If we wanted to compromise, I'd
> rather have \df do what it does today, to keep backwards-compat and
> not confuse users, and \dfU to do what I want 99% of the time.
This seems to me to be the compromise most likely to dissatisfy everyone
Stephen,
On a seperate (kind of) note, I'd really like to be able to say "I want
this function visible everywhere" like a system function. public really
doesn't fit this bill very well, in my experience.
We're *so* not going there. If you really want this, just log in as
superuser and add t
* Joshua D. Drake (j...@commandprompt.com) wrote:
> I like this behavior. A lot.
ditto.
> That was a little irritating but I get the point. The schema functions
> is not in my search path. So:
That's exactly right, imv.. I've got schemas with tons of functions in
them, I don't want to see ever
Josh Berkus writes:
>> Well, maybe we do need to go with the \df \dfS \dfU approach.
>> But I'm still convinced that setting things up so that it's impossible
>> to search both classes of functions together is a seriously bad idea.
> Agreed -- there are times I *want* to search the system functio
On Thu, 2009-01-15 at 14:32 -0800, Josh Berkus wrote:
> Tom,
>
> Personally, I don't care that much about what Hungarian Notation we use,
> as long as we try to make it consistent with \dt, \dv, \dn etc. My main
> objection to requiring \dfU to get only user functions is that it's not
> what
>> On the other hand, I want to look at and search my user-defined
>> functions FREQUENTLY. I don't care about the system functions. If I
>> type \df a*, it's not because I want to see all 6 versions of the
>> absolute value function and 61 other functions, it's because I don't
>> want to think h
Tom,
Well, maybe we do need to go with the \df \dfS \dfU approach.
But I'm still convinced that setting things up so that it's impossible
to search both classes of functions together is a seriously bad idea.
Agreed -- there are times I *want* to search the system functions, and
for less-train
Robert Haas writes:
> You seem to be assuming that conflicts between user-defined functions
> and system functions are a common problem against which users need
> protection. I have been using PostgreSQL for almost 10 years and am
> not sure that I've EVER had a problem with this.
Probably not,
* Robert Haas (robertmh...@gmail.com) wrote:
> On the other hand, I want to look at and search my user-defined
> functions FREQUENTLY. I don't care about the system functions. If I
> type \df a*, it's not because I want to see all 6 versions of the
> absolute value function and 61 other functions
Josh Berkus writes:
> BTW, is this patch even under consideration for 8.4?
It's already committed --- remember the start of the thread was Peter
complaining that he'd already been annoyed by the new behavior. (As
had I, but I'd not gotten round to complaining yet.)
If we wait till after 8.4 is
> 2. You want to write "\df something". Fine, that's not going to show
> any system functions anyway, unless there are system functions that are
> also selected by "something". If there are, it's not apparent to me why
> it's a bad idea to show them; as I've already argued, I think not
> showing
Tom,
I'm unimpressed with the idea of a \system switch, because it will still
be breaking your \df queries hours after you forgot you used it to
adjust \dt. (This argument holds no matter which way you prefer as
default.)
H, OK.
BTW, is this patch even under consideration for 8.4? If no
> You're ignoring the fact that tables and functions are different and
> are used differently. In particular, most of the system catalogs are
> not really meant to be used directly by users, which is surely not
> true for functions and operators.
>
> However, having said that, I'm not averse to un
Josh Berkus writes:
>> You *think* you don't want to see system objects.
> I'm still a consultant for a living, so I use the psql command line on a
> variety of client systems a lot. And I'll tell you that 80% of the time
> I use \df it's to look up the exact spelling and parameters of a
> us
I wrote:
> "Robert Haas" writes:
>> I'm not sure whether you're endorsing that approach or panning it, but
>> -1 from me. We have always had \d or \dt for user tables and \dS or
>> \dtS for system tables. No one is complaining about this AFAICS, so
>> we should \df be any different?
> You're ig
Tom,
You *think* you don't want to see system objects. The first time that
you waste hours trying to figure out why your function doesn't work,
only to find that it conflicts with a system function that \df wasn't
showing you, you'll reconsider.
I'm still a consultant for a living, so I use t
"Robert Haas" writes:
> I'm not sure whether you're endorsing that approach or panning it, but
> -1 from me. We have always had \d or \dt for user tables and \dS or
> \dtS for system tables. No one is complaining about this AFAICS, so
> we should \df be any different? The only argument I can se
On Thu, Jan 15, 2009 at 3:03 PM, Josh Berkus wrote:
>> The real problem here is that the 'S' suffix for \dt is a bad precedent
>> for everything else. If you want consistency then we need to change
>> that end of things. I think that the idea of a switch to omit system
>> objects, rather than in
Josh Berkus writes:
> I disagree. Most users, most of the time, do not want to see system
> objects.
I remain of the opinion that this opinion is wrong, and is based on
lack of experience with the committed patch.
You *think* you don't want to see system objects. The first time that
you waste
Tom,
The real problem here is that the 'S' suffix for \dt is a bad precedent
for everything else. If you want consistency then we need to change
that end of things. I think that the idea of a switch to omit system
objects, rather than include them, might work.
I disagree. Most users, most o
"Robert Haas" writes:
>> However, having said that, I'm not averse to unifying the behavior
>> as long as it's done in a sensible fashion. Imposing the old behavior
>> of \dt on everything else is simply not that sensible fashion.
> Do you have another proposal?
> Although I agree with you that
On Thu, Jan 15, 2009 at 01:06:22PM -0500, Tom Lane wrote:
> Bruce Momjian writes:
> > Well, this is psql and it should be easy; I am not sure
> > pg_catalog.* fits that requirement.
>
> It should be easy for common cases, which I argue "I need to see
> *only* system objects" is not.
Neither is
> BTW, it might be worth pointing out that \d has never worked like that;
> for instance "\d pg_class" gives me an answer anyway. So holding up the
> table behavior as a model of consistency that other \d commands should
> emulate is a pretty weak argument to begin with.
So in 8.3.5, which is wha
> I think searching for both user and system stuff with a pattern is a
> no-brainer.
I'm not sure whether you're endorsing that approach or panning it, but
-1 from me. We have always had \d or \dt for user tables and \dS or
\dtS for system tables. No one is complaining about this AFAICS, so
we s
Bruce Momjian writes:
> Well, this is psql and it should be easy; I am not sure pg_catalog.*
> fits that requirement.
It should be easy for common cases, which I argue "I need to see *only*
system objects" is not.
> Right now if you do \dt you see user tables, and
> \dtS shows system tables; I
Rod Taylor writes:
> Right now pg_catalog sneaks its way onto the search_path for everybody. That
> is fine for execution but information listing like this should probably
> ignore those additions.
Actually, the single worst, most misleading, pernicious and dangerous
aspect of the currently commi
On Thu, Jan 15, 2009 at 09:49:59AM -0800, Joshua D. Drake wrote:
> \df output wraps at 1024x768 which greatly limits usability as a whole.
> I hadn't noticed this until today as my workstation video card exploded
> and I have a temporary one that can't do more than 1024x768 with linux.
> Dropping t
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> I think people use \df all the time to check the argument list, verify
> >> whether they remember the function name correctly, etc. It's not for
> >> "learning about" stuff you never heard of, it's for remembering details
> >> (as i
Bruce Momjian writes:
> Tom Lane wrote:
>> I think people use \df all the time to check the argument list, verify
>> whether they remember the function name correctly, etc. It's not for
>> "learning about" stuff you never heard of, it's for remembering details
>> (as indeed is the usage for user-
On Thu, 2009-01-15 at 12:36 -0500, Tom Lane wrote:
> "Brendan Jurd" writes:
> > Most people wanting to learn about which system functions are
> > available will be surely be going to the manual, not using \df?
>
> I think people use \df all the time to check the argument list, verify
> whether th
Tom Lane wrote:
> "Brendan Jurd" writes:
> > Most people wanting to learn about which system functions are
> > available will be surely be going to the manual, not using \df?
>
> I think people use \df all the time to check the argument list, verify
> whether they remember the function name corre
"Brendan Jurd" writes:
> Most people wanting to learn about which system functions are
> available will be surely be going to the manual, not using \df?
I think people use \df all the time to check the argument list, verify
whether they remember the function name correctly, etc. It's not for
"le
On Fri, Jan 16, 2009 at 03:59:47AM +1100, Brendan Jurd wrote:
> Most people wanting to learn about which system functions are
> available will be surely be going to the manual, not using \df?
Presently the only way you'll get a list of functions that operate on
large objects is to use \df. They m
I would settle for just following the search path as set by the user.
If you explicitly include pg_catalog in the search path, then you should see
those settings.
If you do not explicitly include pg_catalog on the search_path, then it
should not find those items.
Right now pg_catalog sneaks its
>> > The basic goal of the patch was to make 'S' consistent for all \d
>> > backslash commands, and we had a lot of discussion about it, and many
>> > people asked for it (I can't find my user functions).
>>
>> I think this falls in the category of "be careful what you wish for,
>> you might get it
On Fri, Jan 16, 2009 at 3:45 AM, Greg Sabino Mullane wrote:
> The problem is that you, me, and the people we know are the only ones
> who actually use \df to see system functions. 99.99% of users don't care,
> or don't even know, about the system functions - but they do care about
> being able to
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> I think this falls in the category of "be careful what you wish for,
> >> you might get it". It is now blindingly obvious that the folks asking
> >> for that had not actually lived with the behavior for any period of
> >> time.
>
>
Bruce Momjian writes:
> Tom Lane wrote:
>> I think this falls in the category of "be careful what you wish for,
>> you might get it". It is now blindingly obvious that the folks asking
>> for that had not actually lived with the behavior for any period of
>> time.
> I got several emails thanking
On Thu, 2009-01-15 at 11:45 -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
>
> I got several emails thanking me for applying the patch, so there is
> clearly user-demand for 'S'. I think _we_ as developers look at the
> system stuff a lot but in user-land, they would ra
Tom Lane wrote:
> Bruce Momjian writes:
>> The basic goal of the patch was to make 'S' consistent for all \d
>> backslash commands, and we had a lot of discussion about it, and many
>> people asked for it (I can't find my user functions).
>
> I think this falls in the category of "be careful what
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> This patch has annoyed me twice in two days now, and similarly with
> other people I know. Having to type \dfS now is about the worst loss of
> usability in psql that I can recall. Can we reconsider or revert this?
The problem is that you, m
Tom Lane wrote:
> Bruce Momjian writes:
> > The basic goal of the patch was to make 'S' consistent for all \d
> > backslash commands, and we had a lot of discussion about it, and many
> > people asked for it (I can't find my user functions).
>
> I think this falls in the category of "be careful w
Bruce Momjian writes:
> The basic goal of the patch was to make 'S' consistent for all \d
> backslash commands, and we had a lot of discussion about it, and many
> people asked for it (I can't find my user functions).
I think this falls in the category of "be careful what you wish for,
you might
Heikki Linnakangas wrote:
> Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> >> Bruce Momjian wrote:
> Here's an updated version of the psql backslash patch that should
> apply cleanly to the current HEAD. To recap, this makes all the \dX
> commands (most importantly to most: \df)
Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian wrote:
Here's an updated version of the psql backslash patch that should
apply cleanly to the current HEAD. To recap, this makes all the \dX
commands (most importantly to most: \df) work like \dt does, in that it
requires a \dXS to see
Peter Eisentraut writes:
> This patch has annoyed me twice in two days now, and similarly with
> other people I know. Having to type \dfS now is about the worst loss of
> usability in psql that I can recall. Can we reconsider or revert this?
I agree, this change mostly sucks, and particularly
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> >> Here's an updated version of the psql backslash patch that should
> >> apply cleanly to the current HEAD. To recap, this makes all the \dX
> >> commands (most importantly to most: \df) work like \dt does, in that it
> >> requires a \dXS to see sys
--On Donnerstag, Januar 15, 2009 17:51:35 +0200 Peter Eisentraut
wrote:
This patch has annoyed me twice in two days now, and similarly with other
people I know. Having to type \dfS now is about the worst loss of
usability in psql that I can recall. Can we reconsider or revert this?
I'd lik
Bruce Momjian wrote:
Here's an updated version of the psql backslash patch that should
apply cleanly to the current HEAD. To recap, this makes all the \dX
commands (most importantly to most: \df) work like \dt does, in that it
requires a \dXS to see system items. See the archives for much more
di
> Here's an updated version of the psql backslash patch that should
> apply cleanly to the current HEAD. To recap, this makes all the \dX
> commands (most importantly to most: \df) work like \dt does, in that it
> requires a \dXS to see system items. See the archives for much more
> discussion on t
> 2. the help.c patch no longer applies
>
> 3. the help.c patch breaks alignment of the help output
Attached is a patch to fix problems 2 and 3: help.c clean application and
formatting of the output therein. I also put \z right after \dp and removed
the duplicate wording, to make it fit better,
82 matches
Mail list logo
