On Mon, 2007-28-05 at 13:54 -0400, Neil Conway wrote:
> Okay, attached is a patch that does this. To summarize, the changes are:
>
>* add tmask bits for msec, usec (I reordered the #defines to keep
> them logically contiguous, but AFAICS this isn't necessary)
>* if the user specifies
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2007-28-05 at 15:05 -0400, Tom Lane wrote:
>> Hmmm ... if you check the cvs history for those tests you might find
>> some evidence.
> "Modify regression tests to allow GEQ optimizer (order results).",
> according to the 1997 CVS commit from Thomas
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2007-28-05 at 15:38 -0400, Tom Lane wrote:
>> More generally, I'm really hoping to get rid of bespoke text<->whatever
>> cast functions in favor of using datatypes' I/O functions.
> I don't object, but I'm curious: is there a benefit to this other
On Mon, 2007-28-05 at 15:05 -0400, Tom Lane wrote:
> Right. I guess you misunderstood me: I was arguing for rejecting double
> occurrences of the same unit name, but not occurrences of different unit
> names that we happen to map into the same interval field internally.
Makes sense to me. I'll se
On Mon, 2007-28-05 at 15:38 -0400, Tom Lane wrote:
> More generally, I'm really hoping to get rid of bespoke text<->whatever
> cast functions in favor of using datatypes' I/O functions.
I don't object, but I'm curious: is there a benefit to this other than
brevity of implementation? ISTM the spec
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, so the patch is ready to be applied?
Neil's still reviewing it, last I heard.
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
I'll take another stab at refining this can of worms I opened. The one
thing I noticed on a quick review is that it's almost possible to skip all
the calls to gettimeofday if log_checkpoints is off now. I'd like to make
that a specific goal, because that will make me feel better that adding
t
On Mon, 28 May 2007, Tom Lane wrote:
But maybe that could be fixed if the clock sweep doesn't touch the
usage_count of a pinned buffer. Which in fact it may not do already ---
didn't look.
StrategyGetBuffer doesn't care whether the buffer is pinned or not; it
decrements the usage_count rega
OK, so the patch is ready to be applied?
---
NikhilS wrote:
> Hi,
>
> > I agree this will unnecessary add arguments to the DefineIndex API. If we
> > > stick to the patch's earlier way of converting the Oid to names for jus
Gregory Stark <[EMAIL PROTECTED]> writes:
> Is there a reason UnpinBuffer has to be the one to increment the usage count
> anyways? Why can't ReadBuffer handle incrementing the count and just trust
> that it won't be decremented until the buffer is unpinned anyways?
That's a good question. I thin
"Tom Lane" <[EMAIL PROTECTED]> writes:
> A point I have not figured out how to deal with is that in the patch as
> given, UnpinBuffer needs to know the strategy; and getting it that info
> would make the changes far more invasive. But the patch's behavior here
> is pretty risky anyway, since the
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> One idea is to keep track which pins are taken using the bulk strategy.
> It's a bit tricky when a buffer is pinned multiple times since we don't
> know which ReleaseBuffer corresponds which ReadBuffer, but perhaps we
> could get away with just a
Tom Lane wrote:
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
It's assumed that the same strategy is used when unpinning, which is
true for the current usage (and apparently needs to be documented).
I don't believe that for a moment. Even in the trivial heapscan case,
the last pin is typical
On Mon, 2007-05-28 at 21:25 +0100, Heikki Linnakangas wrote:
> - RequestCheckpoint and CreateCheckpoint was changed to take a
> CheckpointReason enum as argument, instead of boolean flags. This allows
> printing a different message depending on the cause of checkpoint, and
> is also cleaner IMH
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> A point I have not figured out how to deal with is that in the patch as
>> given, UnpinBuffer needs to know the strategy; and getting it that info
>> would make the changes far more invasive. But the patch's behavior here
>> is pr
Here's a work-in-progress updated version of this patch. It's not
completed, but I've settled on:
- a log_checkpoints GUC variable to control whether anything is printed
or not. This is in line with log_connections, log_autovacuum etc.
- when checkpoints are logged, LOG-level is used
- the f
Tom Lane wrote:
... and not guaranteeing to reset theaccess pattern on failure, either.
Good catch, I thought I had that covered but apparently not.
I think we've got to get rid of the global variable and make the access
pattern be a parameter to StrategyGetBuffer, instead. Which in turn
sug
Neil Conway <[EMAIL PROTECTED]> writes:
> (2) The spec also requires that boolean::varchar(n) should raise an
> error if "n" is not large enough to accomodate the textual
> representation of the boolean value.
Really? That's in direct contradiction to the "normal" spec-required
behavior of castin
I noticed that SQL:2003 specifies explicit casts between "boolean" and
the character string types. Attached is a patch that implements them,
and adds some simple regression tests.
A few points worth noting:
(1) The SQL spec requires that text::boolean trim leading and trailing
whitespace from the
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2007-28-05 at 10:50 -0400, Tom Lane wrote:
>> I'd argue that it's an oversight. I don't have a problem with adding up
>> the values of units that really translate to the same thing (eg,
>> '1 week 1 day' -> '8 days'), but I think '1 second 2 second
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Here's a new version, all known issues are now fixed. I'm now happy with
> this patch.
I'm looking this over and finding it fairly ugly from a
system-structural point of view. In particular, this has pushed the
single-global-variable StrategyHintV
On Sun, 20 May 2007, Andrew Dunstan wrote:
I've had a preference for INSERT from the beginning here that this
reinforces.
COPY is our standard bulk insert mechanism. I think arguing against it would
be a very hard sell.
Let me say my final peace on this subject...if I considered this data to
On Mon, 2007-28-05 at 10:50 -0400, Tom Lane wrote:
> I'd argue that it's an oversight. I don't have a problem with adding up
> the values of units that really translate to the same thing (eg,
> '1 week 1 day' -> '8 days'), but I think '1 second 2 second' should
> be rejected because it's almost ce
Neil Conway <[EMAIL PROTECTED]> writes:
> Is there any reason to why DecodeInterval() is willing to accept
> multiple specifications for some time units but not others?
I'd argue that it's an oversight. I don't have a problem with adding up
the values of units that really translate to the same th
24 matches
Mail list logo
