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
Marko Kreen wrote:
>
> entab did not compile for me (cvs head), as
> gcc 3.3.5 #error's on .
>
> This patch includes and also converts
> arg declaration to ANSI style, because K&R varargs
> are mystery to me.
Patch applied, with adjustments so it compiles without using c.h. I
actually did not
Marko Kreen wrote:
> There was a patch applied against entab/halt.c that converts
> it away from K&R varargs. But it's buggy, its makes halt()
> use second argment as format string, not first.
>
> Following patch fixes it, but also converts entab/entab.c away
> from K&R.
>
> That is from my own
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
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
On Fri, May 27, 2005 at 01:58:05PM -0400, Robert Treat wrote:
> 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 command
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, while there are undoubtedl
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 judgment ;-)
regards, tom lane
-
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.
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 cas
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 backp
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!
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 conf
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 i
Peter,
> Files that are not actually configuration files, to be edited by users,
> do not belong in the configuration directory.
Do you have an alternate suggestion then? Current behavior is broken.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---(end
Bruce Momjian 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.
Unfortunately, that is *absolu
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
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 willi
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?
--
Alvaro Herrera ()
"El realista sabe lo que quiere; el idealista q
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
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 wei
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'
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.
---
a_
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 stor
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 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 have a
cut-rate SQL lexe
26 matches
Mail list logo
