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
the same
Stephen Frost sfr...@snowman.net 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
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
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
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
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.
I
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?:
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 was a lot
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
later applied any
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 how it was supposed to
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 come
* 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 doesn't
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
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 TODO list.
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
--On Donnerstag, Januar 15, 2009 17:51:35 +0200 Peter Eisentraut
pete...@gmx.net 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
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 system items.
Peter Eisentraut pete...@gmx.net 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
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
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) work like \dt does,
Bruce Momjian br...@momjian.us 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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
-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, me,
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
On Thu, 2009-01-15 at 11:45 -0500, Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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,
Bruce Momjian br...@momjian.us 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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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.
On Fri, Jan 16, 2009 at 3:45 AM, Greg Sabino Mullane g...@turnstep.com 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
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. It is now
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
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
Brendan Jurd dire...@gmail.com 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.
Tom Lane wrote:
Brendan Jurd dire...@gmail.com 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
On Thu, 2009-01-15 at 12:36 -0500, Tom Lane wrote:
Brendan Jurd dire...@gmail.com 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
Bruce Momjian br...@momjian.us 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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
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 the
Rod Taylor rod.tay...@gmail.com 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
Bruce Momjian br...@momjian.us 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
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
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 what I
On Thu, Jan 15, 2009 at 01:06:22PM -0500, Tom Lane wrote:
Bruce Momjian br...@momjian.us 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.
Robert Haas robertmh...@gmail.com 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
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
Josh Berkus j...@agliodbs.com 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
On Thu, Jan 15, 2009 at 3:03 PM, Josh Berkus j...@agliodbs.com 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,
Robert Haas robertmh...@gmail.com 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
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
I wrote:
Robert Haas robertmh...@gmail.com 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?
Josh Berkus j...@agliodbs.com 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
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
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
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 them is
Josh Berkus j...@agliodbs.com 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
* 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,
Robert Haas robertmh...@gmail.com 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
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
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 hard
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 we do
Josh Berkus j...@agliodbs.com 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
* 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 every
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
Stephen Frost sfr...@snowman.net 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
On Thu, 2009-01-15 at 20:25 -0500, Tom Lane wrote:
Stephen Frost sfr...@snowman.net 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.
On Thu, Jan 15, 2009 at 8:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Stephen Frost sfr...@snowman.net 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%
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:
* 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.
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net 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
Josh Berkus j...@agliodbs.com 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
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 want
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Josh Berkus j...@agliodbs.com 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
Stephen Frost sfr...@snowman.net 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
* 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
Stephen Frost sfr...@snowman.net 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,
Tom Lane escribió:
Stephen Frost sfr...@snowman.net 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
* 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 (in
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,
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
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
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 functions
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 the
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
