Tom Lane wrote:
> Well, the patch says that the command line switch wins, which is
> consistent with what we do for other command line switches (they all
> override the equivalent postgresql.conf entries). This does seem a
> bit at variance with the stated goal of making the configuration more
> c
[EMAIL PROTECTED] wrote:
>>I just had a thought about this: seems like a big part of the objection
>>is the risk of specifying -C and -D that don't go together. Well, what
>>if they were the same switch? Consider the following simplification of
>>the proposed patch:
>>
>>
>
>I was really exc
Bruce Momjian wrote:
>Thomas Swan wrote:
>
>
>>I thought the idea was to *reduce* the number of config files and provide
>>a unified configuration file. Ideally, the unified configuration file
>>could eliminate the need for environment variables altogether.
>>
>>If I understand this correctly,
> I just had a thought about this: seems like a big part of the objection
> is the risk of specifying -C and -D that don't go together. Well, what
> if they were the same switch? Consider the following simplification of
> the proposed patch:
I was really excited about this idea, then I thought a
I just had a thought about this: seems like a big part of the objection
is the risk of specifying -C and -D that don't go together. Well, what
if they were the same switch? Consider the following simplification of
the proposed patch:
1. Postmaster has just one switch, '-D datadir' with fallback
> -Original Message-
> From: Jürgen Cappel [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 12, 2004 12:33 PM
> To: Dann Corbit
> Cc: [EMAIL PROTECTED]
> Subject: Re: [HACKERS] 7.5 beta version]
>
>
>
> Point 1 I completely agree on: byte order, alignment,
> padding, etc. is different f
To prevent this, I changed the
behavior of SET search_path so that it validates its input.
... It would be possible to make interactive SET behave differently
from the non-interactive case,
Wait a minute --- scratch what I said above; interactive "SET
search_path" already does behave differently f
> -Original Message-
> From: Jeroen T. Vermeulen [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 12, 2004 1:00 PM
> To: Dann Corbit
> Cc: Bruce Momjian; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] 7.5 beta version
>
>
> On Mon, Apr 12, 2004 at 12:35:15PM -0700, Dann Corbit wrote:
>
> >
> [EMAIL PROTECTED] wrote:
>> > The bottom line to me is that config versus data ought to be a one-to-
>> > many relationship, at least if you accept the premise that shared
>> config
>> > is reasonable at all. Putting a datadir spec inside the config file
>> > makes it impossible to share config
On Mon, Apr 12, 2004 at 12:35:15PM -0700, Dann Corbit wrote:
> I do know of important differences in compilers in this regard. You can
> (for instance) have 80 bit floating point on one compiler using double
> but it is only 64 bits on another.
But in the case of x86 (among others) that's the
On Mon, Apr 12, 2004 at 11:55:45AM -0700, Dann Corbit wrote:
> 1.
> The C language does not define alignment of structs.
Platform ABI standards do, though (hence the "as long as it adheres to..."
clause in my previous post). Whether it's in the C language or in the
platform's ABI standards is
> -Original Message-
> From: Jeroen T. Vermeulen [mailto:[EMAIL PROTECTED]
> Sent: Monday, April 12, 2004 12:25 PM
> To: Dann Corbit
> Cc: Bruce Momjian; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] 7.5 beta version
>
>
> On Mon, Apr 12, 2004 at 11:55:45AM -0700, Dann Corbit wrote:
>
> >
Point 1 I completely agree on: byte order, alignment, padding, etc.
is different for each platform and data cannot directly be exchanged.
Point 2: who really needs C++ ??
Ursprüngliche Nachricht
Betreff: Re: [HACKERS] 7.5 beta version
Datum: Mon, 12 Apr 2004 11:55:45 -0700
V
[EMAIL PROTECTED] writes:
>> Well, it doesn't *require* it, but if you actually *use* the patch in
>> the proposed way then you end up with the error-prone need to specify
>> the correct combination of -C and -D on the command line. I think what
>> people are questioning is whether we can't find a
> -Original Message-
> From: Jeroen T. Vermeulen [mailto:[EMAIL PROTECTED]
> Sent: Sunday, April 11, 2004 7:28 AM
> To: Bruce Momjian
> Cc: Dann Corbit; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] 7.5 beta version
>
>
> On Mon, Apr 05, 2004 at 09:38:13PM -0400, Bruce Momjian wrote:
> >
>
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > ... it isn't clear which files to touch. After the reorganization it
> > would be:
>
> > PG_VERSION global/ postmaster.opts
> > base/ pg_clog/postmaster.pid
> >
Peter Eisentraut wrote:
> Tom Lane wrote:
> > It's certainly ungood, but I don't think we can materially improve
> > things without a fundamental rewrite along the lines of Peter's
> > proposal to support per-column locale/encoding. Database-level
> > settings are simply the wrong tool for this.
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> ... it isn't clear which files to touch. After the reorganization it
> would be:
> PG_VERSION global/ postmaster.opts
> base/ pg_clog/postmaster.pid
> etc/
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > My personal opinion is that we should move the config files from
> > pgsql/data to pgsql/data/etc. Unix config files aren't put in /,
> > they are in /etc, so this seems logical. I was never comfortable
> > with having editable files right next t
Dann Corbit wrote:
> The response from the Mingw team:
> >Comment By: Earnie Boyd (earnie)
>
> Date: 2004-04-08 07:33
>
> Message:
> Logged In: YES
> user_id=15438
>
> Symbolic links to files and directories do not work on Win32
> in general. Support for symlink operation is limited to the source
Tom Lane wrote:
> It's certainly ungood, but I don't think we can materially improve
> things without a fundamental rewrite along the lines of Peter's
> proposal to support per-column locale/encoding. Database-level
> settings are simply the wrong tool for this.
Well, the complete redo is about t
Bruce Momjian wrote:
> My personal opinion is that we should move the config files from
> pgsql/data to pgsql/data/etc. Unix config files aren't put in /,
> they are in /etc, so this seems logical. I was never comfortable
> with having editable files right next to files that shouldn't be
> touche
Bruce Momjian <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
> What if someone does -C /var/data/postgresql.conf, and postgresql.conf
> say to use /usr/local/data for data, what do we do?
Well, the patch says that the command line switch wins, which is
consistent with what we do for other
On Sun, Apr 04, 2004 at 07:41:38PM -, Greg Sabino Mullane wrote:
> I am trying to get version 7.4.2 installed on a Solaris box, but
> initdb fails because of shmmax being set too low. It does this
You'll have to fix shmmax. I've never been able to get postgres
started (since 7.0) on Solaris w
[EMAIL PROTECTED] wrote:
> > The bottom line to me is that config versus data ought to be a one-to-
> > many relationship, at least if you accept the premise that shared config
> > is reasonable at all. Putting a datadir spec inside the config file
> > makes it impossible to share config files acr
> Stephan Szabo <[EMAIL PROTECTED]> writes:
>> On Mon, 12 Apr 2004, Bruce Momjian wrote:
>>> I think the major problem with your -C & -D idea is that you require
>>> the
>>> administrator to link the config file and data directory everytime you
>>> start the db, and that might be error-prone.
>
>>
Fabien,
> I agree that listening is something difficult, for me as for every body.
> Also, listening and talking in another language is not easy.
I can understand that. I'm going to reply at length, here, because there is
a principle behind so many of us rejecting your suggestion, and I'd like
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Mon, 12 Apr 2004, Bruce Momjian wrote:
>> I think the major problem with your -C & -D idea is that you require the
>> administrator to link the config file and data directory everytime you
>> start the db, and that might be error-prone.
> Well, AFAICS
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > My personal opinion is that we should move the config files from
> > pgsql/data to pgsql/data/etc. Unix config files aren't put in /, they
> > are in /etc, so this seems logical. I was never comfortable with having
> > editable files
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Obviously, we need to do something. There are just too many people who
>> want improvement in this area. The question is what changes to make.
[snip]
>
> The whole discussion reminds me quite a bit of Tom Lockhart's patch to
> specify WAL file locati
Bruce Momjian <[EMAIL PROTECTED]> writes:
> My personal opinion is that we should move the config files from
> pgsql/data to pgsql/data/etc. Unix config files aren't put in /, they
> are in /etc, so this seems logical. I was never comfortable with having
> editable files right next to files that
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Obviously, we need to do something. There are just too many people who
> > want improvement in this area. The question is what changes to make.
>
> As far as I've seen in this thread, there's only *one* person arguing
> for change,
> The only other idea I can think of is to create a new pg_path.conf file.
> It would have the same format as postgresql.conf, but contain
> information about /data location, config file location, and perhaps
> pg_xlog location.
>
> The file would be created by special flags to initdb, and once cr
> [EMAIL PROTECTED] wrote:
>> > The only other idea I can think of is to create a new pg_path.conf
>> file.
>> > It would have the same format as postgresql.conf, but contain
>> > information about /data location, config file location, and perhaps
>> > pg_xlog location.
>> >
>> > The file would be
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Obviously, we need to do something. There are just too many people who
> want improvement in this area. The question is what changes to make.
As far as I've seen in this thread, there's only *one* person arguing
for change, and even he isn't advocating
Thomas Swan wrote:
> I thought the idea was to *reduce* the number of config files and provide
> a unified configuration file. Ideally, the unified configuration file
> could eliminate the need for environment variables altogether.
>
> If I understand this correctly, the author was adding the abi
On Mon, 12 Apr 2004, Bruce Momjian wrote:
> [EMAIL PROTECTED] wrote:
> > > The only other idea I can think of is to create a new pg_path.conf file.
> > > It would have the same format as postgresql.conf, but contain
> > > information about /data location, config file location, and perhaps
> > > pg
[EMAIL PROTECTED] wrote:
> > The only other idea I can think of is to create a new pg_path.conf file.
> > It would have the same format as postgresql.conf, but contain
> > information about /data location, config file location, and perhaps
> > pg_xlog location.
> >
> > The file would be created by
On Mon, 12 Apr 2004, Fabien COELHO wrote:
> > Please see my previous e-mail about the value of international standards
> > for educators.
>
> I read your email. I noticed that you want to educate me as an educator;-)
> I partially agree with your point.
>
> We have two words in French: "education
I said:
> Sean Chittenden <[EMAIL PROTECTED]> writes:
>> To prevent this, I changed the
>> behavior of SET search_path so that it validates its input.
> ... It would be possible to make interactive SET behave differently
> from the non-interactive case,
Wait a minute --- scratch what I said abov
Fabien COELHO <[EMAIL PROTECTED]> writes:
> Thus I'd like to add a user defined default public acl for postgresql
> database, namespace, class, language and proc, instead of the hardwired
> defaults in "src/backend/utils/adt/acl.c".
I'm unconvinced that this is a good idea. In the first place I a
Sean Chittenden <[EMAIL PROTECTED]> writes:
> Two reasons come to mind. First, If you change your search_path to a
> valid schema that you have no access to and try and look for database
> objects, you get the impression that its an empty schema and not a
> schema that you don't have access to.
On Sunday 11 April 2004 11:56, [EMAIL PROTECTED] wrote:
> > On Sat, Apr 10, 2004 at 03:53:49PM -0400, [EMAIL PROTECTED] wrote:
> For all the people who would like PostgreSQL to fit in a FHS system,
> easily, they will probably use it. In fact, I would bet real money, that
> if this functionality is
> The only other idea I can think of is to create a new pg_path.conf file.
> It would have the same format as postgresql.conf, but contain
> information about /data location, config file location, and perhaps
> pg_xlog location.
>
> The file would be created by special flags to initdb, and once cre
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes:
> On Sun, Apr 11, 2004 at 10:21:30PM -0400, Bruce Momjian wrote:
>> I was not sure if Win32 had standard alignment for C.
> Good point. There's standards, and then there's Windows. It's possible
> that separate "tight-packing" and "regular" pragm
Dear hackers,
I'm used to have a "umask 077", but I cannot have that at the time with
postgresql. This fact is among the many various "surprises" I had while
discovering postgresql, and this is easy to fix.
Thus I'd like to add a user defined default public acl for postgresql
database, namespace
Dear Josh,
> > Still dreaming.
> And still not listening, I guess.
I agree that listening is something difficult, for me as for every body.
Also, listening and talking in another language is not easy.
> You can create your own, C-like operators any time you want to.
I ***already*** did that.
On Sun, Apr 11, 2004 at 10:21:30PM -0400, Bruce Momjian wrote:
> I was not sure if Win32 had standard alignment for C.
Good point. There's standards, and then there's Windows. It's possible
that separate "tight-packing" and "regular" pragmas are used there, just
for structs that are expected t
The only other idea I can think of is to create a new pg_path.conf file.
It would have the same format as postgresql.conf, but contain
information about /data location, config file location, and perhaps
pg_xlog location.
The file would be created by special flags to initdb, and once created,
would
49 matches
Mail list logo
