Re: [PATCHES] [BUGS] CC Date format code defaults to current centry

2005-03-17 Thread Karel Zak 
On Sun, 2005-03-13 at 21:24 -0500, Bruce Momjian wrote:
 Joe Brown wrote:
  joe= select to_date('19450323','CCYYMMDD');
to_date  
  
   2045-03-23
  (1 row)
  
  joe= select to_date('19450323','MMDD');
to_date  
  
   1945-03-23
  (1 row)
  
  I thought the former would be more correct.  But it seems I am mistaken.
 
 Uh, 1945 _is_ in the 20th century, but I can see how it is confusing.

It ignored CC value if there was YY (, ..). And YY=45 is 2045:

 /*
  * 2-digit year
  */
 if (tmfc-year  70)
   tmfc-year += 2000;
 else
   tmfc-year += 1900;


 I think it's very special case when you define YY and CC and code
should detects it and counts year as (CC-1)*100+YY. The right answers:

CC+YY

test=# select to_date('20450112', 'CCYYDDMM');
  to_date

 1945-12-01

CC+Y

test=# select to_date('2090112', 'CCYDDMM');
  to_date

 1909-12-01


For YYY/ it ignore CC option.

The patch (with docs changes) is in the attachment.

Karel


-- 
Karel Zak [EMAIL PROTECTED]


formatting-17032005.patch.gz
Description: GNU Zip compressed data

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])

Re: [PATCHES] WIP: avoiding tuple construction/deconstruction overhead

2005-03-17 Thread a_ogawa 

Tom Lane wrote:
 Attached is the current state of a patch to reduce the overhead of
 passing tuple data up through many levels of plan nodes.

It is a good idea. 
I think that this patch improves performance of the whole executor.

I have three comments.

(1)We can improve compare_heap() by using TableTupleSlot instead of
HeapTuple. Please see attached patch.

(2)In ExecStoreTuple(), we can omit initialization of slot-tts_nvalid.
If slot-tts_isempty is false, tts_nvalid is initialized by
ExecClearTuple(). If it is true, tts_nvalid is always zero.

(3)There is a description of slot-val in comment of execTuple.c.
This had better revise it.

 Finally, I have made some progress towards making the tuple access
 routines consistently use "bool isNull" arrays as null markers, instead
 of the char 'n' or ' ' convention that was previously used in some but
 not all contexts.

I agree. I think that this progress improves readability.

regards,

--- Atsushi Ogawa

compare_heap.patch
Description: Binary data

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [PATCHES] WIP: avoiding tuple construction/deconstruction overhead

2005-03-17 Thread Tom Lane 
a_ogawa [EMAIL PROTECTED] writes:
 (1)We can improve compare_heap() by using TableTupleSlot instead of
 HeapTuple. Please see attached patch.

Did you measure any performance improvement from that?  I considered it
but thought it would likely be a wash or a loss, because in most cases
only one attribute will be pulled from a tuple during comparetup_heap.
slot_getattr cannot improve on heap_getattr in that case, and is quite
likely to be slower.

 (3)There is a description of slot-val in comment of execTuple.c.
 This had better revise it.

Drat, how'd I miss that?  Thanks.

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [PATCHES] refactor preprocess_targetlist

2005-03-17 Thread Neil Conway 
Neil Conway wrote:
This patch moves some code for preprocessing FOR UPDATE from 
grouping_planner() to preprocess_targetlist(), according to a comment in 
grouping_planner(). I think the refactoring makes sense, and moves some 
extraneous details out of grouping_planner().
Applied.
-Neil
---(end of broadcast)---
TIP 6: Have you searched our list archives?
  http://archives.postgresql.org