- How does the above point affect full dumps that include schema and
data? In my proposal, the copy commands will run as the user running
the script, not the table owner anymore. Presumably, the user running
the script is a superuser. Given that it is possible for a table owner
to revoke th
I worded that badly. I meant "allow a user to change the owner of
something to what it already is". ie. Just make the no-op allowed by
everyone. session_auth already does this.
Ah. Okay, no objection to that. (In fact I believe we put in the
special case for session_auth for exactly the sam
In article <[EMAIL PROTECTED]> you wrote:
> Fellow Perlers and other interested parties,
>
> This is an invitation to participate in the plperlNG project,
Right. I just patched the code so it can drop in to CVS HEAD. It's
at pgFoundry right now.
Also, I've already got at least one Perl group
Simon Riggs <[EMAIL PROTECTED]> writes:
> Is that something you'd be able to do as a starting point for the other
> changes? It's easier for a committer to do this, than for me to do it
> and then another to review it...
I'm up to my eyeballs in tablespaces right now, but if you can wait a
couple
hi,
To see the query results in native language see
http://database.sarang.net/?inc=read&aid=5368&criteria=pgsql&subcrit=qna&id=&limit=20&keyword=&page=1
the simpler url is
http://database.sarang.net/?criteria=pgsql
becase there is no korean postgresql list. poster is "joesp"
basically the c
On Wed, 2004-06-16 at 02:49, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Implementation wise, I would expect all of this code to go in xlog.c,
> > with the recovery target code living in ReadRecord().
>
> I'd like to keep it out of there, as xlog.c is far too big and complex
> a
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
Answering my own question, the distribution of the current logfile
name could be done trough a file handle.
would you mind commenting on my suggestion so I can continue on that topic?
There is no portable way to redistribu
Tom Lane wrote:
That was another point I was about to make, which is that there are lots
of other reasons why the active value of some config variable might not
be what postgresql.conf says. We are *not* ripping out the entire GUC
facility just because some people haven't bothered to read the
docu
Andreas Pflug <[EMAIL PROTECTED]> writes:
>> Answering my own question, the distribution of the current logfile
>> name could be done trough a file handle.
> would you mind commenting on my suggestion so I can continue on that topic?
There is no portable way to redistribute a file handle.
[ BCC to hackers.]
SRA America, based in New York City, is looking for a summer intern or
part-time consultant to assist Bruce Momjian in developing training
classes and certification tests. The training materials already exist,
but it needs to be reorganized and exams created.
The applicant mus
Andreas Pflug <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>
> >Andreas Pflug <[EMAIL PROTECTED]> writes:
> >
> >> How about *requiring* to set any variable, at least to xxx='default'?
> >
> >Don't like that ... we are not in the fascism business here ;-).
It would just make it too hard to add
Tom Lane wrote:
> Andreas Pflug <[EMAIL PROTECTED]> writes:
> > How about vars overridden on the postmaster command line? Similar issue,
> > I believe. Naively, I'd assume that my last instruction (in this case:
> > changing postgresql.conf and SIGHUP) would determine processing, which
> > is ob
Andreas Pflug wrote:
Andreas Pflug wrote:
We agreed long ago that the
postmaster should never depend on the correctness of any shared memory
data structure; but this patch would make it do so.
I understand that, so what's the suggested way to store data common
for all backends?
Answering my o
Andreas Pflug <[EMAIL PROTECTED]> writes:
> How about vars overridden on the postmaster command line? Similar issue,
> I believe. Naively, I'd assume that my last instruction (in this case:
> changing postgresql.conf and SIGHUP) would determine processing, which
> is obviously wrong if I read th
With today being June 16th, we are half-way into the one month extension
of the feature freeze, now scheduled for July 1. Here is the status on
the various outstanding features:
Tablespaces - This has been in the queue since June 1 and should have
been reviewed and applied by now
Tom Lane wrote:
Andreas Pflug <[EMAIL PROTECTED]> writes:
How about *requiring* to set any variable, at least to xxx='default'?
Don't like that ... we are not in the fascism business here ;-).
Well enforcing setting variables, in the presence of a preconfigured
file isn't exactly fasci
Andreas Pflug <[EMAIL PROTECTED]> writes:
> How about *requiring* to set any variable, at least to xxx='default'?
Don't like that ... we are not in the fascism business here ;-).
How would you enforce it anyway?
The idea of special-casing
var = default
(with no quotes around 'default') d
Greg Stark wrote:
Tom Lane <[EMAIL PROTECTED]> writes:
The only real problem I see is that showing all the values as comments
encourages the idea that you can undo a change by undoing your edit.
The simple and obvious fix is to not show the values as comments ...
I agree.
A good way how to
Tom, folks:
> The only real problem I see is that showing all the values as comments
> encourages the idea that you can undo a change by undoing your edit.
> The simple and obvious fix is to not show the values as comments ...
I'll say!I've been testing PostgreSQL.conf settings, writing docs
Stephen Frost wrote:
* Greg Stark ([EMAIL PROTECTED]) wrote:
Tom Lane <[EMAIL PROTECTED]> writes:
The only real problem I see is that showing all the values as comments
encourages the idea that you can undo a change by undoing your edit.
The simple and obvious fix is to not show the values
* Greg Stark ([EMAIL PROTECTED]) wrote:
> Tom Lane <[EMAIL PROTECTED]> writes:
> > The only real problem I see is that showing all the values as comments
> > encourages the idea that you can undo a change by undoing your edit.
> > The simple and obvious fix is to not show the values as comments ...
Fellow Perlers and other interested parties,
This is an invitation to participate in the plperlNG project,
pgFoundry's first registered project. As you may know, plperl for
PostgreSQL currently has severely limited capabilities. PLperlNG is a
project designed to pull together two efforts at
Tom Lane <[EMAIL PROTECTED]> writes:
> The only real problem I see is that showing all the values as comments
> encourages the idea that you can undo a change by undoing your edit.
> The simple and obvious fix is to not show the values as comments ...
Well even if you don't show them (and it wou
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> No, you don't. That allows non-superusers to give away object
>> ownership, which is well-established as a security hole; Unix
>> filesystems stopped doing it years ago.
> I worded that badly. I meant "allow a user to change the owner of
>
I think this is wrong, primarily because it's gonna be seriously
incompatible with existing dump files. The existing technique is
that each TOC entry says who owns the object. You should use that
information and not have to rely on new additions to the file format.
Hrm. OK, i might be able to do
On Wednesday 16 June 2004 03:39, Michael Glaesemann wrote:
> On Jun 16, 2004, at 1:05 PM, Christopher Kings-Lynne wrote:
> >>> The proposal is to remove the comments from postgresql.conf (like
> >>> Apache) so all entries will be active. The downside is that it will
> >>> not
> >>> be possible to
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Christopher Kings-Lynne wrote:
>> One thing that truly annoys me about postgresql.conf is say I unhash an
>> option and set it to something. Then I reload. Then I edit the conf
>> and hash it out again, then I reload. Of course, the option still has
Christopher Kings-Lynne wrote:
> >>The proposal is to remove the comments from postgresql.conf (like
> >>Apache) so all entries will be active. The downside is that it will not
> >>be possible to determine which values were modified from their defaults.
>
> One thing that truly annoys me about po
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> This brings up a question for Chris, which is whether he's implemented
>> this in a way that forces the decision at pg_dump time, or whether
>> it is made during pg_restore.
> I've implented it exactly like comments are implemented. I just cr
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> There is one other consideration, and that is that current pg_dump likes
> to set session_auth to user of object before outputting drop command,
> when '-c' is specificed.
> I propose that we eliminate that set session_auth as well. If the u
Oh dear, a lot of typos here, hopefully still decipherable... apologies.
Mark
Mark Kirkwood wrote:
This seems like a nice idea -
It might even be worth targeting a couple pf specific "ranges" - e.g :
machines with 1G RAM and 4G RAM ( "medium" are "large" come to mind,
I know it's a bit like that
This seems like a nice idea -
It might even be worth targeting a couple pf specific "ranges" - e.g :
machines with 1G RAM and 4G RAM ( "medium" are "large" come to mind, I
know it's a bit like that "other" database product we know of but
that doesn't mean it's necessarily bad!)
Mark
Christ
Would it help to have two lines in the config file for each setting, one
with the default (comment) and one with the actual setting? So for
example, the postgresql.conf would ship with something like this:
#tcpip_socket = false #default
tcpip_socket = false
Even better, have a postgresql.
On Jun 16, 2004, at 1:05 PM, Christopher Kings-Lynne wrote:
The proposal is to remove the comments from postgresql.conf (like
Apache) so all entries will be active. The downside is that it will
not
be possible to determine which values were modified from their
defaults.
One thing that truly anno
34 matches
Mail list logo
