The documentation about this is a little brief (reading from the
developer docs, section 4.1.2.1.).
Does the SQL standard provide no way to have a NULL character in a
string constant? Is single-quote the only special character?
If I have a system on 7.4 or 8.0 right now, what is the recommended
"
On Mon, Aug 01, 2005 at 10:35:00PM -0400, Jeff MacDonald wrote:
> On Mon, Aug 01, 2005 at 10:22:14PM -0400, Matthew T. O'Connor wrote:
> [..snipped..]
> > Right which is why we would need to enforce some max value so that
> > vacuuming will never be totally squeezed out.
> I'm a linux guy, so plea
On Mon, Aug 01, 2005 at 10:22:14PM -0400, Matthew T. O'Connor wrote:
[..snipped..]
>
> Right which is why we would need to enforce some max value so that
> vacuuming will never be totally squeezed out.
>
greetings,
I'm a linux guy, so please forgive my ignorance, but is it even possible to
det
Andrew - Supernews wrote:
On 2005-08-01, "Matthew T. O'Connor" wrote:
* Stop a running VACUUM if the system load is too high.
What if vacuum used a vacuum delay that was equal to the vacuum delay
GUC settings * the system load. Or something more sophisticated but
this would have
On 2005-08-01, "Matthew T. O'Connor" wrote:
>>* Stop a running VACUUM if the system load is too high.
>
> What if vacuum used a vacuum delay that was equal to the vacuum delay
> GUC settings * the system load. Or something more sophisticated but
> this would have the effect of having vacuum a
All the items you mentioned look like 8.2 issues to me. But here are
some thoughts.
Alvaro Herrera wrote:
* Enable autovacuum by default.
Get some field experience with it first, so the worst bugs are covered.
(Has anybody tested it?)
I have done some testing and it seems to be work
On Mon, Aug 01, 2005 at 11:58:34AM -0700, Joshua D. Drake wrote:
> What might this be?
Whether to warn on '\' in non-E'' strings.
AFAIK Bruce wants to turn this to 'on' in 8.2.
--
marko
---(end of broadcast)---
TIP 9: In versions below 8.0, the
Hello,
What might this be?
Sincerely,
Joshua D. Drake
--
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandp
Jonah,
Thanks for your comments.
Jonah H. Harris writes:
> I have a lot of shell scripts that run as cron jobs and have considered
> this option. However, if you look at it carefully, SQL is totally
> different from say perl, php, bash, etc. for scripts which execute from
> the shell. To
> > > > I fail to see how this is better than just editing the
> > > file. Because
> > > > it basically *is* a file editing function limited to
> pg_hba.conf.
> > > > Perhaps what we need is a file reader/writer that is
> > > hardcoded to the
> > > > pg_hba.conf file?
> > >
> > > It allows remo
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: 01 August 2005 15:36
> To: Magnus Hagander
> Cc: Dave Page; Tom Lane; PostgreSQL-development
> Subject: Re: [HACKERS] Remote administration functionality
>
> Uh, not sure why it would be harder. What system w
Magnus Hagander wrote:
> > > The difference is that if the other admin edited it in vi
> > *last week*
> > > it will still break with your way, unless every admin
> > always rembers
> > > to do
> > > load_pg_hba() before doing *anything at all*.
> >
> > Yes, good point. In thinking about thi
* Dave Page (dpage@vale-housing.co.uk) wrote:
> > Alright, sorry to just jump in here in the middle, but I don't see why
> > pg_hba.conf couldn't be made to work just like pg_shadow (or rather,
> > pg_authid or whatever it is now :).
>
> Because the admin doesn't edit pg_shadow using vi or some
* Dave Page (dpage@vale-housing.co.uk) wrote:
> > This isn't actually an argument against my proposal. The
> > admin doesn't
> > edit pg_shadow using vi because it's understood to be 'owned' by the
> > database. The same would be true of 'pg_hba' in my solution.
>
> Only if it were moved to a d
> -Original Message-
> From: Stephen Frost [mailto:[EMAIL PROTECTED]
> Sent: 01 August 2005 15:51
> To: Dave Page
> Cc: Bruce Momjian; Andreas Pflug; Tom Lane; Magnus Hagander;
> PostgreSQL-development
> Subject: Re: [HACKERS] Remote administration functionality
>
>
> This isn't actua
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> writes:
> > Alright, sorry to just jump in here in the middle, but I don't see why
> > pg_hba.conf couldn't be made to work just like pg_shadow (or rather,
> > pg_authid or whatever it is now :).
>
> (1) pg_hba.conf is funda
> -Original Message-
> From: Douglas McNaught [mailto:[EMAIL PROTECTED]
> Sent: 01 August 2005 15:16
> To: Dave Page
> Cc: Bruce Momjian; Tom Lane; Magnus Hagander; PostgreSQL-development
> Subject: Re: [HACKERS] Remote administration functionality
>
> "Dave Page" writes:
>
> >
> >
"Dave Page" writes:
>
>
>> -Original Message-
>> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
>> I am thinking we will need load_pg_hba() and write_pg_hba() that will
>> load and write the table to pg_hba.conf.
>
> Yeah, that bit is straghtforward enough, but what about the situation
> -Original Message-
> From: Stephen Frost [mailto:[EMAIL PROTECTED]
> Sent: 01 August 2005 15:41
> To: Bruce Momjian
> Cc: Andreas Pflug; Dave Page; Tom Lane; Magnus Hagander;
> PostgreSQL-development
> Subject: Re: [HACKERS] Remote administration functionality
>
> > > >>The problem
Stephen Frost <[EMAIL PROTECTED]> writes:
> Alright, sorry to just jump in here in the middle, but I don't see why
> pg_hba.conf couldn't be made to work just like pg_shadow (or rather,
> pg_authid or whatever it is now :).
(1) pg_hba.conf is fundamentally order-sensitive; SQL tables are
fundament
> > >>The problem is, pg_hba.conf might be editted via the OS unlike the text
> > >>version of pg_shadow which is only editted via the server, which would
> > >>make appropriate locking nigh-on impossible afaics.
Alright, sorry to just jump in here in the middle, but I don't see why
pg_hba.conf co
Magnus Hagander wrote:
>The difference is that if the other admin edited it in vi *last week* it
>will still break with your way, unless every admin always rembers to do
>load_pg_hba() before doing *anything at all*.
What if you send patches over the wire rather than the whole or
subsets of the f
Andreas Pflug wrote:
> Bruce Momjian wrote:
>
> >>
> >>Isn't the pg_hba.conf situation quite the same as postgresql.conf? The
> >>GUCs with pg_settings is the GUC like a table, but with comments that
> >>exceed config_generic.long_desc.
> >
> >
> > Well, pg_hba.conf is ordered,
>
> From a t
> > The difference is that if the other admin edited it in vi
> *last week*
> > it will still break with your way, unless every admin
> always rembers
> > to do
> > load_pg_hba() before doing *anything at all*.
>
> Yes, good point. In thinking about this, I think we are
> better having the
> -Original Message-
> From: Magnus Hagander [mailto:[EMAIL PROTECTED]
> Sent: 01 August 2005 15:18
> To: Bruce Momjian
> Cc: Dave Page; Tom Lane; PostgreSQL-development
> Subject: RE: [HACKERS] Remote administration functionality
>
> > It allows remote administration, and by using col
Bruce Momjian wrote:
Isn't the pg_hba.conf situation quite the same as postgresql.conf? The
GUCs with pg_settings is the GUC like a table, but with comments that
exceed config_generic.long_desc.
Well, pg_hba.conf is ordered,
From a text editor user's view, postgresql.conf is ordered too
Magnus Hagander wrote:
> > > > I am thinking we will need load_pg_hba() and write_pg_hba() that
> > > > will load and write the table to pg_hba.conf.
> > >
> > > Yeah, that bit is straghtforward enough, but what about the
> > situation
> > > where dba #1 updates the pg_hba table, at the same ti
On Mon, Aug 01, 2005 at 12:28:55AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Luke Lonergan wrote:
> >> Has there been any agreement or a concept for remote reboot?
>
> > Reload of config file and rotate log files were part of the original
> > patch that I will try to apply. I am not sur
Andreas Pflug wrote:
> Bruce Momjian wrote:
> > Dave Page wrote:
>
> >>The problem is, pg_hba.conf might be editted via the OS unlike the text
> >>version of pg_shadow which is only editted via the server, which would
> >>make appropriate locking nigh-on impossible afaics.
> >>
> >>Unless you're a
> > > I am thinking we will need load_pg_hba() and write_pg_hba() that
> > > will load and write the table to pg_hba.conf.
> >
> > Yeah, that bit is straghtforward enough, but what about the
> situation
> > where dba #1 updates the pg_hba table, at the same time as
> dba #2 is
> > editting pg
Dave Page wrote:
>
>
> > -Original Message-
> > From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> > Sent: 01 August 2005 01:35
> > To: Dave Page
> > Cc: Tom Lane; Magnus Hagander; PostgreSQL-development
> > Subject: Re: [HACKERS] Remote administration functionality
> >
> > I am thinking
Bruce Momjian wrote:
Dave Page wrote:
The problem is, pg_hba.conf might be editted via the OS unlike the text
version of pg_shadow which is only editted via the server, which would
make appropriate locking nigh-on impossible afaics.
Unless you're advocating only allowing pg_hba modifications
> -Original Message-
> From: Bruce Momjian [mailto:[EMAIL PROTECTED]
> Sent: 01 August 2005 01:35
> To: Dave Page
> Cc: Tom Lane; Magnus Hagander; PostgreSQL-development
> Subject: Re: [HACKERS] Remote administration functionality
>
> I am thinking we will need load_pg_hba() and write_
33 matches
Mail list logo
