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 you may have
> Tom Lane wrote:
>> [EMAIL PROTECTED] writes:
>> > I am neither suggesting nor implementing any change in the current
>> default
>> > behavior of PostgreSQL. I am merely adding features that would make it
>> > easier to do things like configure from a centralized directory which
>> is
>> > differe
Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > I am neither suggesting nor implementing any change in the current default
> > behavior of PostgreSQL. I am merely adding features that would make it
> > easier to do things like configure from a centralized directory which is
> > different than the d
> [EMAIL PROTECTED] writes:
>> I am neither suggesting nor implementing any change in the current
>> default
>> behavior of PostgreSQL. I am merely adding features that would make it
>> easier to do things like configure from a centralized directory which is
>> different than the data directory, th
[EMAIL PROTECTED] writes:
> I am neither suggesting nor implementing any change in the current default
> behavior of PostgreSQL. I am merely adding features that would make it
> easier to do things like configure from a centralized directory which is
> different than the data directory, the ability
>
> On Fri, 9 Apr 2004, Christopher Browne wrote:
>>
>> ...Tom ... commented that all of the core developers make extensive use
>> of the notion of having _many_ backends around, and therefore ...
>>
>> Core folk aren't likely to write up patches designed to shoot
>> themselves in the foot this way
Fabien,
> With "extended", I could have c-like operators;-) : ! && || == !=
>
> Still dreaming.
And still not listening, I guess.
You can create your own, C-like operators any time you want to. In fact, you
could launch a project on pgFoundry (as soon as it's up) for a package of
C-like o
> But making == a synonym for = is just syntactic sugar,
Sure.
> of no obvious practical benefit that I can see.
I can see a small practical benefit, as I could skip the expression part
of my course just by telling them "same as java". No big deal, I agree.
> I think its alleged utility in tea
I try to install postgresql7.4.2 on macosx from source
when initdb create conversions it tell me
cound not access $libdir/ascii_and_mic file
can somebody tell me how to resolve it
thanks
---(end of broadcast)---
TIP 2: you can get off all
Fabien COELHO said:
>
>
> So on the point that the standard must be supported, I perfectly agree.
>
> On the point that anything else should be dropped out: let's do it!
> I'll send a patch to remove all those non portable features in
> postgresql that make users write non portable code... But I'm
Dear Jan,
> > If you want to promote postgreSQL, then it should be good that anything
> > from outside (whether standard or not) can work with postgreSQL, but
> > anything that work in pg may not work outside;-)
>
> I couldn't disagree more. What you are asking for is to do whatever (you
> think)
> > Could we consider a three (or more) way setting, for what to do?
> > Something like:
> >
> > sql_noncompliance_mode = error;
> > sql_noncompliance_mode = warn / notice;
> > sql_noncompliance_mode = ignore;
>
> I think a boolean that turns on warnings would be enough.
Hmmm.
I could think of:
12 matches
Mail list logo
