Tom Lane wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Attached is my backslash consistency patch which basically makes
all the backslash commands behave as \dt does: \d* shows non-system
objects, and \d*S shows system objects.
Could we have a way to turn this off? At least for
On Fri, 2005-05-27 at 03:45, Peter Eisentraut wrote:
Tom Lane wrote:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Attached is my backslash consistency patch which basically makes
all the backslash commands behave as \dt does: \d* shows non-system
objects, and \d*S shows system
Robert Treat [EMAIL PROTECTED] writes:
Do you have an implementation in mind? I'm having trouble coming up with
a way to do it cleanly.
A psql \set variable to choose the behavior seems like a reasonable
compromise. Perhaps it could list the \d commands that should include
system objects by
Peter Eisentraut wrote:
Robert Treat wrote:
I see hardly any use case for showing only user-defined functions
or types by default. I think consistency is not necessarily
desirable here.
See the archives for previous discussion and/or use cases.
I didn't find any. Nevertheless,
On Friday 27 May 2005 15:09, Peter Eisentraut wrote:
Robert Treat wrote:
I see hardly any use case for showing only user-defined functions
or types by default. I think consistency is not necessarily
desirable here.
See the archives for previous discussion and/or use cases.
I
I have generated the following patch that moves postmaster.pid into the
configuration directory. pg_ctl only knows about the configuration
directory because it can't read postgresql.conf, so it seems that is the
right place to move it.
I have tested it and it seems to work. I would like to
FAQ's updated for 8.0.X and current. Thanks.
---
Mahmoud Taghizadeh wrote:
Please update site.
With Regards,
--taghi
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail
Bruce Momjian wrote:
I have generated the following patch that moves postmaster.pid into
the configuration directory. pg_ctl only knows about the
configuration directory because it can't read postgresql.conf, so it
seems that is the right place to move it.
Files that are not actually
Bruce Momjian said:
I have generated the following patch that moves postmaster.pid into the
configuration directory. pg_ctl only knows about the configuration
directory because it can't read postgresql.conf, so it seems that is
the right place to move it.
this seems wrong ... wouldn't it be
Bruce Momjian pgman@candle.pha.pa.us writes:
I have generated the following patch that moves postmaster.pid into the
configuration directory. pg_ctl only knows about the configuration
directory because it can't read postgresql.conf, so it seems that is the
right place to move it.
On Fri, May 27, 2005 at 04:16:15PM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
How about a psql config option? It should default to show only
non-system objects, as that is the most generally useful behavior.
There seems to be a distinct lack of unanimity about that
Robert Treat [EMAIL PROTECTED] writes:
On Friday 27 May 2005 15:09, Peter Eisentraut wrote:
I didn't find any. Nevertheless, while there are undoubtedly some uses
for everything, making this the default behavior does not seem
acceptable.
ISTM it is more acceptable than you're willing to
Alvaro Herrera [EMAIL PROTECTED] writes:
On Fri, May 27, 2005 at 07:40:17PM -0400, Tom Lane wrote:
I really think we have only two choices: teach pg_ctl how to dig the
data directory location out of postgresql.conf,
I don't think this is extremely hard, isn't it?
One small problem is that I
Alvaro Herrera [EMAIL PROTECTED] writes:
On Fri, May 27, 2005 at 04:16:15PM -0400, Tom Lane wrote:
There seems to be a distinct lack of unanimity about that judgment ;-)
Well, yes, _across Postgres hackers_. But if we were to ask
pgsql-general I have a feeling we would measure more weight on
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
On Fri, May 27, 2005 at 07:40:17PM -0400, Tom Lane wrote:
I really think we have only two choices: teach pg_ctl how to dig the
data directory location out of postgresql.conf,
I don't think this is extremely hard, isn't it?
One
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
Neil, I have added these item to the TODO list. Do you plan on applying
this?
---
Neil Conway wrote:
This patch implements two changes to hash indexes:
- rather than storing the values of the index keys, we just store
I have extracted the COPY \x part of your patch, and have attached it
for later application to CVS for 8.1.
---
Sergey Ten wrote:
Hello all,
Thank you to all who replied for suggestions and help. Enclosed please find
Bruce Momjian pgman@candle.pha.pa.us writes:
Is reading postgresql.conf
from pg_ctl without a parser really accurate?
The brute-force solution is to duplicate guc-file.l.
That seems pretty ugly but in the long run it might be the most
maintainable solution. We eventually gave up trying to
19 matches
Mail list logo
