BTW - on a related note, I was seeing this failure in the tests:
FAIL: runTest
(pgadmin.feature_tests.pg_datatype_validation_test.PGDataypeFeatureTest)
Test checks for PG data-types output
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/Users/dpage/git/pgadmin4/web/pgadmin/feature_tests/pg_datatype_validation_test.py",
line 42, in runTest
self._check_datatype()
File
"/Users/dpage/git/pgadmin4/web/pgadmin/feature_tests/pg_datatype_validation_test.py",
line 111, in _check_datatype
assert False, "{0} does not match with {1}".format(val,
expected_output[cnt])
AssertionError: ARRAY[1, 2, 'nan']::float[] does not match with 1, 2, 'nan'
On Thu, May 11, 2017 at 10:11 AM, Dave Page <dp...@pgadmin.org> wrote:
> Hi
>
> On Thu, May 11, 2017 at 6:38 AM, Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>> Hi,
>>
>> As we have been facing many issues with different data-type display in
>> Query Tool output, Dave suggested to write the feature test for the same.
>>
>> I have started with some basic set of data-type values and will add more.
>> Please find the attached initial patch for the same.
>>
>
> Some thoughts:
>
> - Instead of sleeping, which is almost always a bad design, can we wait
> for objects to appear?
>
> - Currently you're testing each datatype with an individual query, e.g.
>
> SELECT 32768;
>
> I would suggest we test all datatypes at once, e.g.
>
> SELECT 32768, 43723489023489, '2017-09-12 15:34:11', 12345.56;
>
> etc. That will massively reduce the time taken to execute the tests (which
> is a big concern).
>
> - Shouldn't we be casting the values in the SELECT, so we (and the
> database) know exactly what we're expecting? e.g.
>
> SELECT 32768::int, 43723489023489::bigint, '2017-09-12
> 15:34:11':timestamp, 12345.56::numeric(8,4);
>
> That would also allow us to verify the type name displayed in the column
> headers.
>
> Thanks!
>
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
