multibyte regression tests

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:

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:

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

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

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:

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:

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