Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
The consequence will be, though, that psql will accept a syntax for
"\copy (query) ..." that the corresponding backend command would reject
were we not transforming it. That strikes me as potentially confusing.
Perhaps. Wha
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> The consequence will be, though, that psql will accept a syntax for
> "\copy (query) ..." that the corresponding backend command would reject
> were we not transforming it. That strikes me as potentially confusing.
Perhaps. What about plan B: remove
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
oh, good point. OK, I have cut this quick patch that will continue to
accept the legacy syntax in psql in non-inline-query cases, but will
make psql unreservedly emit new style syntax for COPY to the backend.
Does that seem reaso
On Sun, 4 Feb 2007, David Fetter wrote:
> On Fri, Feb 02, 2007 at 07:01:33PM -0800, Jeremy Drake wrote:
>
> > Let me know if you see any bugs or issues with this code, and I am
> > open to suggestions for further regression tests ;)
>
> > Things that I still want to look into:
> > * regexp flags (
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> BTW I've got serious reservations about whether this bit is safe:
>>
>>> + /* The table could've grown since vacuum started, and
>>> there
>>> +* might already be dead tuples on the new pages
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> oh, good point. OK, I have cut this quick patch that will continue to
> accept the legacy syntax in psql in non-inline-query cases, but will
> make psql unreservedly emit new style syntax for COPY to the backend.
> Does that seem reasonable, or is it
Bruce Momjian writes:
> Attached is a patch that errors for \r and \n in delimiter and
> null.
I am not convinced that this is a bug. Can you prove that there is no
use-case for asking COPY to emit data in this style? Sure, COPY itself
couldn't read it, but people sometimes feed COPY output to
On Fri, Feb 02, 2007 at 07:01:33PM -0800, Jeremy Drake wrote:
> Let me know if you see any bugs or issues with this code, and I am
> open to suggestions for further regression tests ;)
> Things that I still want to look into:
> * regexp flags (a la regexp_replace).
One more text field at the end
Hello,
I am sorry for preview chotic mails. My web email client is stupid (I am
too).
This patch correct bug, when localized day or month names was incorectly
trnasformed to lower or upper string.
Regards
Pavel Stehule
_
Najde
This short patch was too short. I send (I hope) last correct version.
Multibyte lower, upper functions are called only for localized names, for
others we call pg_tolower or pg_toupper still.
Regards
Pavel Stehule
Hello,
it's more correct patch and more short.
Regards
Pavel Stehule
Wou
This short patch is too short. I send (I hope) last correct version.
Multibyte lower, upper functions are called only for localized names, for
others we call pg_tolower or pg_toupper still.
Regards
Pavel Stehule
Hello,
it's more correct patch and more short.
Regards
Pavel Stehule
Woul
This short patch is too short. I send (I hope) last correct version.
Multibyte lower, upper functions are called only for localized names, for
others we call pg_tolower or pg_toupper still.
Regards
Pavel Stehule
Hello,
it's more correct patch and more short.
Regards
Pavel Stehule
Woul
Hello,
it's more correct patch and more short.
Regards
Pavel Stehule
Would you please modify this patch to use the functions in
oracle_compat.c?
---
Pavel Stehule wrote:
> Hello,
>
> this patch correct bug in to_char
On Sat, 2007-02-03 at 20:37 -0500, Bruce Momjian wrote:
> Your patch has been added to the PostgreSQL unapplied patches list at:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches
>
> It will be applied as soon as one of the PostgreSQL committers reviews
> and approves it.
Tom applied th
14 matches
Mail list logo
