> > > Since 8.1 has done this all along and no one's actually
> complained
> > > about it, I guess no one is using scripts that do "cd". I'm
> > > inclined to go with Bernd's suggestion to change the docs
> to match
> > > the code, but does anyone have a contrary opinion?
>
> > In Unix you c
Simon Riggs wrote:
> On Fri, 2006-11-03 at 17:34 +0100, Martijn van Oosterhout wrote:
>> On Fri, Nov 03, 2006 at 11:25:09AM -0500, Tom Lane wrote:
>> > Since 8.1 has done this all along and no one's actually complained
>> about
>> > it, I guess no one is using scripts that do "cd". I'm inclined to
On Fri, 2006-11-03 at 17:34 +0100, Martijn van Oosterhout wrote:
> On Fri, Nov 03, 2006 at 11:25:09AM -0500, Tom Lane wrote:
> > Since 8.1 has done this all along and no one's actually complained about
> > it, I guess no one is using scripts that do "cd". I'm inclined to go
> > with Bernd's sugges
> >> To be honest, I have often wondered *why* we support
> kerberos outside
> >> of the uber l33t geek factor. I have not once in a commercial
> >> deployment had a business requirement for the beast. LDAP?
> Now that
> >> is a whole other issue :)
> >
> > Single sign-on in a Windows/AD envi
Tom Lane wrote:
Bernd Helmle <[EMAIL PROTECTED]> writes:
Since 8.1 has done this all along and no one's actually complained about
it, I guess no one is using scripts that do "cd". I'm inclined to go
with Bernd's suggestion to change the docs to match the code, but does
anyone have a contrary opi
Nolan Cafferky wrote:
This may not inform the current conversation at all, but a while back
I went on a cross-compiler compatibility binge for all of my active
projects, and I found that some compilers (*cough* Borland *cough) had
some very strange compiler/run time errors unless all variable
I think Tom stated it pretty well:
When the variable is going to be set anyway in
straight-line code at the top of the function, then it's mostly a
matter of taste whether you set it with an initializer or an assignment.
the key phrase is: "set anyway in straigh-tline code at the top of
On Fri, Nov 03, 2006 at 11:25:09AM -0500, Tom Lane wrote:
> Since 8.1 has done this all along and no one's actually complained about
> it, I guess no one is using scripts that do "cd". I'm inclined to go
> with Bernd's suggestion to change the docs to match the code, but does
> anyone have a contr
>> To be honest, I have often wondered *why* we support kerberos
>> outside of the uber l33t geek factor. I have not once in a
>> commercial deployment had a business requirement for the
>> beast. LDAP? Now that is a whole other issue :)
>
> Single sign-on in a Windows/AD environment (I'm talk
Bernd Helmle <[EMAIL PROTECTED]> writes:
> Our WAL backup documentation says in some parts of it:
> ..."%p is replaced by the absolute path of the file to archive..." [1]
> I think this is (at least for 8.1 and upcoming 8.2 releases) wrong, since
> the archiver replaces this with pg_xlog/ only,
Tom Lane wrote:
"Simon Riggs" <[EMAIL PROTECTED]> writes:
We only care when they break, otherwise its just situation normal, yes?
No, the trouble case is where the XA manager that owns the transaction
has forgotten about it.
Yeah, and there's no way the DBMS can detect that.
Is there a way
On Fri, 3 Nov 2006, Tom Lane wrote:
>
> > Is there a way to see prepared transactions where the original session
> > that prepared then has died? Perhaps the message at startup should be
> > "you have at least one prepared transaction that needs resolution".
>
> I am completely baffled by this foc
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> We only care when they break, otherwise its just situation normal, yes?
No, the trouble case is where the XA manager that owns the transaction
has forgotten about it.
> Is there a way to see prepared transactions where the original session
> that prepar
Zeugswetter Andreas ADI SD wrote:
>
> > Seems like either we go back to ignoring non-connectable
> > databases (with the risks that entails), or adopt some
> > more-aggressive policy for launching autovacuums on them, or
>
> Um, I think we would want to still have the ability to not need to
> f
> Seems like either we go back to ignoring non-connectable
> databases (with the risks that entails), or adopt some
> more-aggressive policy for launching autovacuums on them, or
Um, I think we would want to still have the ability to not need to
frequently vacuum known frozen databases.
Could
> > > > The same could apply to SSL cert based authentication,
> for users
> > > > connecting from machines outside of my realm. Once you have
> > > "unlocked"
> > > > the certificate, you can authenticate any number of
> times to any
> > > > number of services that will accept this certificate
On Fri, 2006-11-03 at 01:48 -0500, Tom Lane wrote:
> I agree that there's a usability issue here though; I've been burnt by
> forgotten prepared xacts myself (eg by control-C'ing pg_regress at just
> the wrong time). Would it help if we included prepared xacts in the
> pg_stat_activity view?
>
17 matches
Mail list logo
