Should we add the multibyte regression tests to the buildfarm test
suite? Does anyone know how portable they are? I guess adding them would
be one way to find out.

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

They should be completely portable (provided the script in src/test/mb runs
on that platform).

- Luke


On 7/12/05 10:54 AM, "Andrew Dunstan" <andrew@dunslane.net> wrote:

>
> Should we add the multibyte regression tests to the buildfarm test
> suite? Does anyone know how portable they are? I guess adding them would
> be one way to find out.
>
> cheers
>
> andrew
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
> choose an index scan if your joining column's datatypes do not
> match
>



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Good. So should we roll this up into the standard regression suite? Why
are these tests separate? Is it just that they need a UTF8 encoded db
rather than an SQL-ASCII encoded db?

cheers

andrew

Luke Lonergan wrote:

>They should be completely portable (provided the script in src/test/mb runs
>on that platform).
>
>- Luke
>
>
>On 7/12/05 10:54 AM, "Andrew Dunstan" <andrew@dunslane.net> wrote:
>
>
>
>>Should we add the multibyte regression tests to the buildfarm test
>>suite? Does anyone know how portable they are? I guess adding them would
>>be one way to find out.
>>
>>
>>

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Andrew,

> Good. So should we roll this up into the standard regression suite? Why
> are these tests separate? Is it just that they need a UTF8 encoded db
> rather than an SQL-ASCII encoded db?

I think that was the idea - the src/test/mb kit was already there and was
designed to create the UTF8 database and controlled circumstances for a
conversion test, so we used it for the similar testing for COPY.

It could possibly be moved into the "make check" regression suite, if the
regression DB is always created with UTF8.

Ayush may be able to add to this.

- Luke



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

Luke Lonergan wrote:

>Andrew,
>
>
>
>>Good. So should we roll this up into the standard regression suite? Why
>>are these tests separate? Is it just that they need a UTF8 encoded db
>>rather than an SQL-ASCII encoded db?
>>
>>
>
>I think that was the idea - the src/test/mb kit was already there and was
>designed to create the UTF8 database and controlled circumstances for a
>conversion test, so we used it for the similar testing for COPY.
>
>It could possibly be moved into the "make check" regression suite, if the
>regression DB is always created with UTF8.
>
>Ayush may be able to add to this.
>
>
>
>

It isn't. But we now have support in pg_regress for specifying the
database explicitly, and we have just adapted the PL regression sets to
use the standard infrastructure that the core and contrib regression
sets use. Moreover, pg_regress.sh already has some support for multibyte
encodings. So I think rolling up the mb tests at least to use a
(possibly enhanced) pg_regress.sh would be a GoodThing (tm). Having a
single and adequately featured regression harness should make adding
specialised test sets easier - I imagine that would appeal to you guys
at GreenPlum :-)

cheers

andrew

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Andrew, Luke,

As pointed by Luke, the reason for using mb regression suite (src/test/mb),
is to consolidate all similar kinds of multi-byte/client encoding tests at
one place.

Thanks,
Ayush

On 7/15/05 1:36 PM, "Luke Lonergan" <llonergan@greenplum.com> wrote:

>
> Andrew,
>
>> Good. So should we roll this up into the standard regression suite? Why
>> are these tests separate? Is it just that they need a UTF8 encoded db
>> rather than an SQL-ASCII encoded db?
>
> I think that was the idea - the src/test/mb kit was already there and was
> designed to create the UTF8 database and controlled circumstances for a
> conversion test, so we used it for the similar testing for COPY.
>
> It could possibly be moved into the "make check" regression suite, if the
> regression DB is always created with UTF8.
>
> Ayush may be able to add to this.
>
> - Luke
>



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

I am totally confused by your response and Luke's. I think we might be
talking completely at cross purposes. My original question had nothing
to do with the COPY patch.

cheers

andrew

Ayush Parashar wrote:

>Andrew, Luke,
>
>As pointed by Luke, the reason for using mb regression suite (src/test/mb),
>is to consolidate all similar kinds of multi-byte/client encoding tests at
>one place.
>
>Thanks,
>Ayush
>
>On 7/15/05 1:36 PM, "Luke Lonergan" <llonergan@greenplum.com> wrote:
>
>
>
>>Andrew,
>>
>>
>>
>>>Good. So should we roll this up into the standard regression suite? Why
>>>are these tests separate? Is it just that they need a UTF8 encoded db
>>>rather than an SQL-ASCII encoded db?
>>>
>>>
>>I think that was the idea - the src/test/mb kit was already there and was
>>designed to create the UTF8 database and controlled circumstances for a
>>conversion test, so we used it for the similar testing for COPY.
>>
>>It could possibly be moved into the "make check" regression suite, if the
>>regression DB is always created with UTF8.
>>
>>Ayush may be able to add to this.
>>
>>- Luke
>>
>>
>>
>
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>
>
>

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

This has been saved for the 8.2 release:

http://momjian.postgresql.org/cgi-bin/pgpatches_hold

---------------------------------------------------------------------------

Andrew Dunstan wrote:
>
>
> Luke Lonergan wrote:
>
> >Andrew,
> >
> >
> >
> >>Good. So should we roll this up into the standard regression suite? Why
> >>are these tests separate? Is it just that they need a UTF8 encoded db
> >>rather than an SQL-ASCII encoded db?
> >>
> >>
> >
> >I think that was the idea - the src/test/mb kit was already there and was
> >designed to create the UTF8 database and controlled circumstances for a
> >conversion test, so we used it for the similar testing for COPY.
> >
> >It could possibly be moved into the "make check" regression suite, if the
> >regression DB is always created with UTF8.
> >
> >Ayush may be able to add to this.
> >
> >
> >
> >
>
> It isn't. But we now have support in pg_regress for specifying the
> database explicitly, and we have just adapted the PL regression sets to
> use the standard infrastructure that the core and contrib regression
> sets use. Moreover, pg_regress.sh already has some support for multibyte
> encodings. So I think rolling up the mb tests at least to use a
> (possibly enhanced) pg_regress.sh would be a GoodThing (tm). Having a
> single and adequately featured regression harness should make adding
> specialised test sets easier - I imagine that would appeal to you guys
> at GreenPlum :-)
>
> cheers
>
> andrew
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

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