Tom Lane wrote:
BTW, rather than hacking the parameter list of ProcessUtility,
I'd be inclined to just look at ActivePortal->portalParams in
PerformCursorOpen. (Come to think of it, we could also copy
ActivePortal's sourceText at the PortalDefineQuery step.)
I've done this and it seems to work fin
I have completed the 7.5 release notes. You can view them in HTML on
the developer web page. I have marked a few items with question marks
that need to be addressed. I am looking for improvements, even minor
ones. Either send in a patch or committers can modify the file
directly.
Of course thi
Oh, yea, now that the release notes are done, I will focus on getting
the outstanding patches applied tomorrow.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ C
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> BTW, are you sure Fabien did not already solve this problem in his
>> pending patch?
> You mean schema ownership? I thought that was just upon the first
> connection to a database or something?
Yeah, but the point was that he was doing an A
If possible ... how painful would it be to do?
I'm yet to do that part, so I guess I'll find out.
Actually it looks like you'd better, because for example aclupdate
assumes there's only one entry for a given grantor/grantee pair.
OK, many thanks for the prompt reply :)
BTW, are you sure Fabien did
Tom Lane <[EMAIL PROTECTED]> writes:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> When I run through the acl changing all references from the old owner to
>> the new owner, should I combine the resulting acls if possible? Because
>> if the new owner already has some acls on that item
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> If I have the nspForm variable (which is a Form_pg_namespace) struct
> pointer, then how do I check if the nspacl field is default (ie.
> "NULL"). This is so I can avoid running DatumGetAclP on it, which seems
> to cause alloc error reports.
Hi,
Usually i'd ply away at this one until I figured it out, but we're
running out of time :)
If I have the nspForm variable (which is a Form_pg_namespace) struct
pointer, then how do I check if the nspacl field is default (ie.
"NULL"). This is so I can avoid running DatumGetAclP on it, which
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Other than the spectacular lack of documentation, I don't think we are
>> in bad shape at all.
> OK, that helps. Alvaro had a number of items floating around and I
> wasn't sure where he was on them. Same with PITR. Once the number
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am _still_ unclear on what still needs to be done to complete NT and
> > PITR. Are you more aware of the open issues?
>
> NT: feature-wise, we need to commit the SAVEPOINT-syntax patch, which
> I think needs only minor adjustments,
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I am _still_ unclear on what still needs to be done to complete NT and
> PITR. Are you more aware of the open issues?
NT: feature-wise, we need to commit the SAVEPOINT-syntax patch, which
I think needs only minor adjustments, and we need to do something
I agree we don't want to add a savepoint on top of the exceptions as you
stated below.
I am _still_ unclear on what still needs to be done to complete NT and
PITR. Are you more aware of the open issues?
---
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
> So it allows functions to use subtransactions and recover from errors.
> I thought that was more than we could do for 7.5 and in fact the release
> notes now saw that will be done in a future release.
I think there's only a day or two's work between her
Tom Lane wrote:
One issue is that it may break existing PLs that override Warn_restart,
since the semantics of doing that will have changed a bit. We can
easily fix the PLs that are in our own CVS, but what are the
implications for other PLs such as PL/R and PL/SH? Joe, Peter, any
comments?
I am
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Yes. This is an integral part of finishing nested transactions.
> Oh, is this exceptions in functions or the ability to allow functions to
> keep executing after an SQL error?
Those are the same thing, aren't they? But yes, that's t
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Are you suggesting these changes for 7.5?
>
> Yes. This is an integral part of finishing nested transactions.
Oh, is this exceptions in functions or the ability to allow functions to
keep executing after an SQL error?
--
Bruce M
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Yes. This is an integral part of finishing nested transactions.
>
> > Oh, is this exceptions in functions or the ability to allow functions to
> > keep executing after an SQL error?
>
> Those are the same thing,
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Are you suggesting these changes for 7.5?
Yes. This is an integral part of finishing nested transactions.
regards, tom lane
---(end of broadcast)---
TIP 1: subscribe and unsubscri
Are you suggesting these changes for 7.5?
---
Tom Lane wrote:
> Currently, the way that ereport/elog processing works is:
>
> 1. Collect up all the error parameter information into an ErrorData
> structure. (This is somewh
Currently, the way that ereport/elog processing works is:
1. Collect up all the error parameter information into an ErrorData
structure. (This is somewhat nontrivial in itself, at least in the
ereport case, but I'll gloss over that here.)
2. Construct a log message and/or a client Error or Notic
On Sat, 2004-07-24 at 15:22, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Calling PreallocXlogFiles outside of the Checkpoint code is
> > straightforward to initiate from bgwriter.c, but the caller must have
> > already obtained the current recptr position. That would require
> > a
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> On Fri, Jul 23, 2004 at 09:49:05AM -0400, Tom Lane wrote:
>> No, at least not if you made that a global change. Doing it that way
>> will mean that a failed subtransaction will not release its locks, no?
> Hmm ... won't they be released when the Resour
On Fri, Jul 23, 2004 at 09:49:05AM -0400, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > I just figured that if we let LockRelation use GetCurrentTransactionId()
> > then the wrong thing happens if we let large objects survive
> > subtransaction commit/abort.
>
> > So I have chan
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> A previous discarded patch used the static var as means of setting an
> abort point when a function was called. The idea was to close all
> subtransactions opened within the function, so that the user wouldn't be
> presented with subtransactions that th
Cc'ed to hackers ...
On Sat, Jul 24, 2004 at 02:10:49PM -0400, Tom Lane wrote:
> > I think I am done with this part. Please review and apply it. The
> > attached patch is probably the same I posted to patches some days ago,
> > only updated with the latest commits.
>
> It looks pretty good, but
Simon Riggs <[EMAIL PROTECTED]> writes:
> Calling PreallocXlogFiles outside of the Checkpoint code is
> straightforward to initiate from bgwriter.c, but the caller must have
> already obtained the current recptr position. That would require
> attempting to gain a lock on XLogCtl, then releasing it
On Thu, 2004-07-22 at 15:19, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Thu, 2004-07-22 at 01:44, Tom Lane wrote:
> >> Agreed. Maybe it should be part of the bgwriter's idle loop, and
> >> not directly associated with checkpoints at all.
>
> > Yes, thats a more natural home,
27 matches
Mail list logo
