Should information hiding be done in psql(1) or should this be managed
by the backend and all logic kept out of psql(1)?
If the intent of this feature is security, it seems totally pointless
to
implement it in psql (leaving aside whether it's actually a good idea
or
not).
[ WRT to search_path an
Bruce Momjian wrote:
Mark Kirkwood wrote:
Bruce Momjian wrote:
My idea was to put config files in /usr/local/pgsql/data/etc, not
pgsql/etc.
We don't put Unix configuration files in /, etc put them in /etc.
Sorry, I missed the 'data' pathname. However - I may be a bit slow - bu
> Alexander Cohen wrote:
>> > Alexander Cohen wrote:
>> >> Has anyone attempted to write a version of pg_ctl in C code? Is it in
>> >> the works anywhere?
>> >
>> > Someone attempted, but never completed it a few months ago, so no, no
>> > one is working on it right now. Use initdb.c as an example
> [EMAIL PROTECTED] wrote:
>> > 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.
>> >
>> > My personal opinion is that we move the config files in /data/etc, and
>> > allow admins to move that direc
> [EMAIL PROTECTED] wrote:
>
>>
>>IMHO my patch can do this in a self
>>documenting way, thus making it easier to do, i.e.
>>
>>postmaster -C /etc/postgres/fundb.conf
>>postmaster -C /etc/postgres/testdb.conf
>>
>>I think that is far more intuitive than:
>>
>>postmaster -D /some/path/who/knows/wher
Alexander Cohen wrote:
> > Alexander Cohen wrote:
> >> Has anyone attempted to write a version of pg_ctl in C code? Is it in
> >> the works anywhere?
> >
> > Someone attempted, but never completed it a few months ago, so no, no
> > one is working on it right now. Use initdb.c as an example.
Just
Mark Kirkwood wrote:
> Bruce Momjian wrote:
>
> > My idea was to put config files in /usr/local/pgsql/data/etc, not
> >
> >pgsql/etc.
> >
> >We don't put Unix configuration files in /, etc put them in /etc.
> >
> >
> >
> Sorry, I missed the 'data' pathname. However - I may be a bit slow - but
>
Bruce Momjian wrote:
My idea was to put config files in /usr/local/pgsql/data/etc, not
pgsql/etc.
We don't put Unix configuration files in /, etc put them in /etc.
Sorry, I missed the 'data' pathname. However - I may be a bit slow - but
I do not see how this will handle the situation where
[EMAIL PROTECTED] wrote:
> > 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.
> >
> > My personal opinion is that we move the config files in /data/etc, and
> > allow admins to move that directory somew
Jeroen T. Vermeulen wrote:
> On Mon, Apr 05, 2004 at 09:38:13PM -0400, Bruce Momjian wrote:
> >
> > I don't think you can mix libs/binaries from different compilers.
>
> As long as it's plain old C, and the compilers adhere to the platform's
> ABI standards, why not? Even if you compile the C co
Mark Kirkwood wrote:
> I seems to me that the existing situation is actually correct :
>
> The configuration is a property of the initialized database cluster, so
> a logical place for it is in the root of said cluster.
>
> It is *not* a property of the installed binary distribution (e.g
> /usr
[EMAIL PROTECTED] wrote:
IMHO my patch can do this in a self
documenting way, thus making it easier to do, i.e.
postmaster -C /etc/postgres/fundb.conf
postmaster -C /etc/postgres/testdb.conf
I think that is far more intuitive than:
postmaster -D /some/path/who/knows/where/fundb
postmaster -D /ano
On Sun, 2004-04-11 at 17:10, Sean Chittenden wrote:
> Should information hiding be done in psql(1) or should this be managed
> by the backend and all logic kept out of psql(1)?
If the intent of this feature is security, it seems totally pointless to
implement it in psql (leaving aside whether it's
Sean Chittenden wrote:
Is hiding schema information a good thing? Do people think that the
concept of "secure by default" should apply to schema information
inside of the database? Should information hiding be done in psql(1)
or should this be managed by the backend and all logic kept out o
[ Discussion moved from patches@ to hackers@ ]
The gist of the discussion being: what are the ramifications of having
PostgreSQL and psql(1) hide information/schema bits that a user doesn't
have access to. This would have to be backend enforced, which would
mean changing the system catalogs to
> On Sat, Apr 10, 2004 at 03:53:49PM -0400, [EMAIL PROTECTED] wrote:
>> > The whole idea of having multiple command-line switches to pick config
>> > and data separately bothers me. ISTM this would mostly create great
>> new
>> > opportunities to shoot yourself in the foot (by accidentally picking
On Sat, Apr 10, 2004 at 03:53:49PM -0400, [EMAIL PROTECTED] wrote:
> > The whole idea of having multiple command-line switches to pick config
> > and data separately bothers me. ISTM this would mostly create great new
> > opportunities to shoot yourself in the foot (by accidentally picking the
> >
On Mon, Apr 05, 2004 at 09:38:13PM -0400, Bruce Momjian wrote:
>
> I don't think you can mix libs/binaries from different compilers.
As long as it's plain old C, and the compilers adhere to the platform's
ABI standards, why not? Even if you compile the C code using a C++
compiler, as in this cas
> I seems to me that the existing situation is actually correct :
>
> The configuration is a property of the initialized database cluster, so
> a logical place for it is in the root of said cluster.
>
> It is *not* a property of the installed binary distribution (e.g
> /usr/local/pgsql/etc) - as yo
19 matches
Mail list logo
