Tom Lane wrote:
But as Peter remarks nearby, this discussion is wasted anyway, because
there is only one correct answer: whatever Oracle does with these
cases is what to_char() should do.
My patch does exactly what Oracle does besides one thing: my code does
not contain a real capitalization f
On Tue, 2008-02-26 at 15:12 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Following patch implements a simple mechanism to keep a buffer pinned
> > while we are bulk loading.
>
> This will fail to clean up nicely after a subtransaction abort, no?
Yes, will fix.
> (For that
Simon Riggs <[EMAIL PROTECTED]> writes:
> Following patch implements a simple mechanism to keep a buffer pinned
> while we are bulk loading.
This will fail to clean up nicely after a subtransaction abort, no?
(For that matter I don't think it's right even for a top-level abort.)
And I'm pretty sur
On Tue, 2008-02-26 at 00:17 -0800, Neil Conway wrote:
> You didn't comment on my proposed solution (FreeTupleDesc() iff refcount
> == -1).
Attached is a revised version of this patch. It makes the
FreeTupleDesc() change described above, and fixes a bug: in
SRF_RETURN_DONE(), we need to be sure to
On Tue, 2008-02-26 at 14:43 +, Simon Riggs wrote:
> Following patch implements a simple mechanism to keep a buffer pinned
> while we are bulk loading.
>
> Performance gains measured as +20% gain for CREATE TABLE as SELECT, and
> 15-17% for COPY on very short rows. Measurable difference drops a
> But as Peter remarks nearby, this discussion is wasted
> anyway, because there is only one correct answer: whatever
> Oracle does with these cases is what to_char() should do.
++1
---(end of broadcast)---
TIP 7: You can help support the Postgre
> This is what you get when you copy a proprietary, poorly
> specified interface.
> The to_char functions are supposed to be Oracle-compatible,
> so we need to check what Oracle does. Whether that is useful
> in practice is a bit secondary.
>
> I'm beginning to think, if you want formatting
Euler Taveira de Oliveira <[EMAIL PROTECTED]> writes:
> FYI, strftime() [1] doesn't say anything about capitalization. I don't
> know if some translators are aware of it and even if they are, how would
> they know that a day or month is the first word of a sentence? IMHO we
> should provide Xxxx
Zdenek Kotala wrote:
But how you handle situation when you have multi language application
which needs correct output for all languages? You cannot use any of the
pattern because it will be wrong for some group of languages.
FYI, strftime() [1] doesn't say anything about capitalization. I don
Am Dienstag, 26. Februar 2008 schrieb Zdenek Kotala:
> But how you handle situation when you have multi language application
> which needs correct output for all languages? You cannot use any of the
> pattern because it will be wrong for some group of languages.
This is what you get when you copy
> No. [Looking at the code...] I think it only affects the
> LC_MESSAGES 'cause setlocale(LC_MESSAGES) don't work on Windows.
In order to make setlocale(LC_MESSAGES) affect on windows some additional
steps must be taken. I don't go deep in that now. I have a fix with
description etc. etc.
> Is
Euler Taveira de Oliveira napsal(a):
Zdenek Kotala wrote:
Yes it is. Only if it is a first word in a sentence or name you should
use "Ú". Also name of day is 'pondělí' (Monday) with small p
But we're not talking about *sentence*, we need to consider just the
*word*. So I think TMMonth should
Zdenek Kotala wrote:
Yes it is. Only if it is a first word in a sentence or name you should
use "Ú". Also name of day is 'pondělí' (Monday) with small p
But we're not talking about *sentence*, we need to consider just the
*word*. So I think TMMonth should be Xxxx, TMMONTH should be
X
Gevik Babakhani wrote:
Have you tested this patch on MSVC and MinGW (Windows) builds?
changing LC_MESSAGES/LC_TIME will most probably break the Windows behavior.
No. [Looking at the code...] I think it only affects the LC_MESSAGES
'cause setlocale(LC_MESSAGES) don't work on Windows.
AFAIK,
For the joy of all of you: that's the correct WIP patch.
At the moment it only tries to create runs uding two heaps. Hope you can
help me with writing those runs on tapes.
I'd be very pleased to give you more details.
Thenks for your time.
Regards, Manolo.
-
Am Dienstag, 26. Februar 2008 schrieb Magne Mæhre:
> I noticed that the dtrace code wouldn't build after the recent SUBSYS.o
> reorganization.
Fixed.
Is there no buildfarm coverage of dtrace?
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadc
Following patch implements a simple mechanism to keep a buffer pinned
while we are bulk loading.
Performance gains measured as +20% gain for CREATE TABLE as SELECT, and
15-17% for COPY on very short rows. Measurable difference drops away and
is not measurable at all at 1000/bytes per row.
As a r
Magne Mæhre wrote:
I noticed that the dtrace code wouldn't build after the recent SUBSYS.o
reorganization.
Attached is a small patch that expands the files..
--Magne
Oooops... wrong patch file
The correct one is attached
Sorry
--Magne
Index: src/backend/Makefile
I noticed that the dtrace code wouldn't build after the recent SUBSYS.o
reorganization.
Attached is a small patch that expands the files..
--Magne
? src/include/probes.h
? src/include/probes_null.h
Index: src/Makefile
===
RCS file:
For the joy of all of you: that's the correct WIP patch.
At the moment it only tries to create runs uding two heaps. Hope you can
help me with writing those runs on tapes.
I'd be very pleased to give you more details.
Thenks for your time.
Regards, Manolo.
Magnus,
Please look at this patch before you check my last patch about the locale.
It seems that Euler's solution also fixes the windows locale bug that I was
trying to fix.
Replacing the lc_messages with lc_time when using to_char seems to be the
correct direction.
I have compiled and tested Eul
> Attached is a patch that replaces the lc_messages with
> lc_time when using to_char in translation mode (TM) [1]. It
> doesn't change the output behaviour. Per discussion [2], it's
> using some cache mechanism so we don't need to call
> setlocale() all the time.
Have you tested this patch on
Tom Lane napsal(a):
"Florian G. Pflug" <[EMAIL PROTECTED]> writes:
Maybe we should just bite the bullet, and implement int64 emulation
for platforms that don't provide one?
Why? Workarounds such as "use double where needed" have served us
perfectly fine so far, with far less effort and notati
Euler Taveira de Oliveira napsal(a):
Zdenek Kotala wrote:
Please, Day names does not have capitalized first letter in Czech
language. We have "pondeli" as a Monday. If locale does not do that it
is probably intention :-).
Hmmm... I don't know about that. I do it that way 'cause I'm concerned
On Tue, 2008-02-26 at 03:13 -0500, Tom Lane wrote:
> "It's OK in the built-in SRFs" is disastrously different from "It's OK".
Right, I never said that, I was just commenting on your view that the
predominant use-case for SRFs is returning refcounted tupdescs.
You didn't comment on my proposed sol
Neil Conway <[EMAIL PROTECTED]> writes:
> On Mon, 2008-02-25 at 21:00 -0500, Tom Lane wrote:
>> I find this part of the patch to be a seriously bad idea.
> AFAICS this is not true of any of the SRFs in the backend, which always
> return expendable tupdescs.
"It's OK in the built-in SRFs" is disas
On Mon, 2008-02-25 at 21:00 -0500, Tom Lane wrote:
> I find this part of the patch to be a seriously bad idea.
> nodeFunctionscan has no right to assume that the function has returned
> an expendable tupdesc; indeed, I would think that the other case is
> more nearly what's expected by the API for
27 matches
Mail list logo
