Changes in v3:
* DEALLOCATE PREPARE ALL
* RESET PLANS wont check for ACL_CREATE_TEMP anymore.
* Add prepare.h and portal.h to guc.c.
On 4/7/07, Neil Conway <[EMAIL PROTECTED]> wrote:
> * RESET SESSION does not ABORT anymore, instead fails if in transaction.
I think it's quite bizarre to hav
On Sat, 2007-04-07 at 22:16 -0400, Bruce Momjian wrote:
> > The patch is faster until we hit 100k or 10% of the table, at which
> > point it is the same speed. What is interesting is 1M is also the same
> > speed:
All tests good, AFAICS. Thanks Bruce.
Patch is operating as expected: the common
On Sat, 2007-04-07 at 18:19 -0400, Bruce Momjian wrote:
> Simon Riggs wrote:
> > On Sat, 2007-04-07 at 11:53 -0400, Bruce Momjian wrote:
> >
> > > This looks useful, but shouldn't it be part of /contrib/pgstattuple
> > > rather than in the backend?
> >
> > Well, this was written with a view to it
On Thu, 2007-04-05 at 22:56 +0100, Simon Riggs wrote:
> transaction_guarantee.v11.patch
correct files attached
> Open Questions
> --
>
> 1. Should the DFC use a standard hash table? Custom code allows both
> additional speed and the ability to signal when it fills.
>
> 2. Should tq
"Simon Riggs" <[EMAIL PROTECTED]> writes:
>> 4. The recent changes to remove CheckpointStartLock haven't changed the
>> code path for deferred transactions, so a similar solution might be
>> possible there also.
> Some further discussion required here, I think. That change may actually
> have intr
On Sun, 2007-04-08 at 11:05 -0400, Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
> >> 4. The recent changes to remove CheckpointStartLock haven't changed the
> >> code path for deferred transactions, so a similar solution might be
> >> possible there also.
>
> > Some further discussi
I've realized that Peter's criticism (concerning comparing beginning
of datum with "".
I'll propose a modification of the patch as long as fixes for NULLs as
input and output values very soon (in a day or so).
On 4/4/07, Nikolay Samokhvalov <[EMAIL PROTECTED]> wrote:
The patch attached contains
Tom Lane wrote:
> True, there doesn't seem to be any point in providing a full syntax
> summary rather than just saying "the SQL spec says you can grant
> privileges on columns but we don't support that yet".
I think it's pretty useful if people see a command of this form from
some other implemen
Bruce Momjian wrote:
> > True, there doesn't seem to be any point in providing a full syntax
> > summary rather than just saying "the SQL spec says you can grant
> > privileges on columns but we don't support that yet".
>
> Agreed. Patch attached and applied. I don't see any other cases of
> this
Bruce Momjian wrote:
> Michael Fuhr wrote:
> > On Fri, Apr 06, 2007 at 11:34:39PM -0400, Bruce Momjian wrote:
> > > Patch applied. Thanks. Your documentation changes can be viewed
> > > in five minutes using links on the developer's page,
> >
> > Thanks. 8.1 and 8.2 have the same typo -- any rea
As discussed on -hackers and -admin... a few minor changes, rolled into
a single patch.
- check we have an archiver to carry away WAL files at shutdown
(was part of task 1)
- archive_mode GUC, on which archive_command is dependent
closing loophole to avoid data loss with wal-avoiding commands
(wa
Tom Lane wrote:
David Fetter <[EMAIL PROTECTED]> writes:
On Mon, Apr 02, 2007 at 10:01:44PM -0400, Alvaro Herrera wrote:
So, hum, what happened to the idea of creating the array types only
on demand?
Scotched, as far as I could tell,
More like "you submitted a patch
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> One of the things that's been bothering me about this proposal is that
> it leaves untouched and indeed greatly expands the scope of the typename
> mangling we do. (i.e. adding an entry to pg_type with _ prepended).
Yeah, that's been bothering me too.
On Sun, Apr 08, 2007 at 07:08:38PM -0400, Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > One of the things that's been bothering me about this proposal is that
> > it leaves untouched and indeed greatly expands the scope of the typename
> > mangling we do. (i.e. adding an entry
Tom Lane wrote:
I've been thinking of proposing that we add a column to pg_type that
points from a type to its array type (if any), ie the reverse link
from typelem. If we had that then the parser could follow that to
determine which type is foo[], instead of relying on the _foo naming
conventi
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I don't suggest that we stop using the naming convention,
>> but it would no longer be a hard-and-fast rule, just a convention.
>> In particular we could rejigger things around the edges to reduce
>> the name conflict problem. For ins
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
I don't suggest that we stop using the naming convention,
but it would no longer be a hard-and-fast rule, just a convention.
In particular we could rejigger things around the edges to reduce
the name conflict pro
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I'm slightly inclined to agree with David that the danger of catalog
> bloat isn't that great, and might not justify the extra work that some
> sort of explicit array creation would involve (e.g. changes in grammar,
> pg_dump), as long as we are agree
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > > True, there doesn't seem to be any point in providing a full syntax
> > > summary rather than just saying "the SQL spec says you can grant
> > > privileges on columns but we don't support that yet".
> >
> > Agreed. Patch attached and applied. I
Tom Lane wrote:
Based on this, I withdraw my efficiency concern about generating
rowtypes for all user tables. I do, however, still object to generating
them for system tables. In particular an array type for pg_statistic
will actively Not Work and probably constitute a security hole, because
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> How would we do that? Not create the array types in bootstrap mode? Or
> just special-case pg_statistic?
Not generate them in bootstrap mode works for me. IIRC, there's code
somewhere in there that allows anyarray to pass as a column type in
bootstrap
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> That doesn't mean this one isn't useful. Please revert this.
> Well, Tom and I thought it caused confusion, as did the person reporting
> the confusion. You saying to revert it isn't enough.
A possible compromise is to descr
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> > I do not understand this patch. You have defined two functions,
> > UTF8MatchText() and UTF8MatchTextIC(), and the difference between them
> > is that one calls CHAREQ and the other calls ICHAREQ, but just above
> > those two functions you define the m
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Peter Eisentraut wrote:
> >> That doesn't mean this one isn't useful. Please revert this.
>
> > Well, Tom and I thought it caused confusion, as did the person reporting
> > the confusion. You saying to revert it isn't enough.
>
> A
Simon, do you have email access while you are away for two weeks? Can
you answer questions via email?
---
Simon Riggs wrote:
> As discussed on -hackers and -admin... a few minor changes, rolled into
> a single patch.
>
> -
On Sun, 2007-04-08 at 23:02 -0400, Bruce Momjian wrote:
> Simon, do you have email access while you are away for two weeks? Can
> you answer questions via email?
It's not a complete blackout, if I check through...
Irregular email 10-12 Apr
Now available 17 Apr half day
Email 19, 21 A
On Sun, 2007-04-08 at 17:02 +0100, Simon Riggs wrote:
> My concern was this:
>
> If we flush the currently outstanding deferred transactions then that
> doesn't guarantee they have all reached the clog. Previously, a deferred
> transaction would not release the CheckpointStartLock until after the
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Michael Fuhr wrote:
> > > On Fri, Apr 06, 2007 at 11:34:39PM -0400, Bruce Momjian wrote:
> > > > Patch applied. Thanks. Your documentation changes can be viewed
> > > > in five minutes using links on the developer's page,
> > >
> > > Thanks. 8.1
28 matches
Mail list logo
