Thread: multibyte regression tests
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
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 >
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. >> >> >>
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: > > 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 >
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 > > >
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, Pennsylvania19073