Обсуждение: [pgScript patch] Improved test output + make use of pgAdmin UI for error output

Hi,

Attached to this email, three patches for pgScript:
1. The first one improves the output of the pgScript integration test
suite: only a bash file has been modified.
2. The second one corrects an extra space introduced in the output
from the previous patch.
3. The third one enables pgScript to use the pgAdmin UI for error
output: when an error occurs while interpreting a script then the line
where the error occurred is signaled.

That's it. Those are the patches I was talking about a few days ago.
Nothing else to add before the beta release.

Best regards,
Mickael

Hi.

On Wed, Mar 11, 2009 at 1:52 PM, Mickael Deloison <mdeloison@gmail.com> wrote:
> Hi,
>
> Attached to this email, three patches for pgScript:
> 1. The first one improves the output of the pgScript integration test
> suite: only a bash file has been modified.

Applied.

> 2. The second one corrects an extra space introduced in the output
> from the previous patch.

Applied.

> 3. The third one enables pgScript to use the pgAdmin UI for error
> output: when an error occurs while interpreting a script then the line
> where the error occurred is signaled.

Testing on Windows, it fails the first tests I try :-(

select * from missing_table

I get no error message at all. If I enter garbage, I just get the following:

1.0: syntax error, unexpected character

If I enter this example from the docs:

SET @A = INTEGER(100, 200);
PRINT @A; -- Prints an integer between 100 and 200
PRINT @A; -- Prints another integer between 100 and 200

I get:

3.9-10: syntax error, unexpected '-'

I would expect an error message from the first query, and nicely
formatted errors from the second and third tests (though actually I
wouldn't expect an error at all from the docs example). FWIW, other
(non-erroring) examples work fine:

SET @PROGR@M#TITLE = 'pgScript';
PRINT '';
PRINT @PROGR@M#TITLE + ' features:';
PRINT '';
PRINT '  * Regular PostgreSQL commands';
PRINT '  * Control-of-flow language';
PRINT '  * Local variables';
PRINT '  * Random data generators';

gives:

[PGSCRIPT ]
[PGSCRIPT ] pgScript features:
[PGSCRIPT ]
[PGSCRIPT ]   * Regular PostgreSQL commands
[PGSCRIPT ]   * Control-of-flow language
[PGSCRIPT ]   * Local variables
[PGSCRIPT ]   * Random data generators

and

DECLARE @I, @T; -- Variable names begin with a @
SET @I = 0; -- @I is an integer
WHILE @I < 20
BEGIN
    SET @T = 'table' + CAST (@I AS STRING); -- Casts @I
    CREATE TABLE @T (id integer primary key, data text);

    SET @I = @I + 1;
END

Outputs the queries and resulting notices as expected.

--
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

Hmm, I see similar results if I revert the patch. I wonder if the one
Magnus applied broke something?

On Wed, Mar 11, 2009 at 5:24 PM, Dave Page <dpage@pgadmin.org> wrote:
> Hi.
>
> On Wed, Mar 11, 2009 at 1:52 PM, Mickael Deloison <mdeloison@gmail.com> wrote:
>> Hi,
>>
>> Attached to this email, three patches for pgScript:
>> 1. The first one improves the output of the pgScript integration test
>> suite: only a bash file has been modified.
>
> Applied.
>
>> 2. The second one corrects an extra space introduced in the output
>> from the previous patch.
>
> Applied.
>
>> 3. The third one enables pgScript to use the pgAdmin UI for error
>> output: when an error occurs while interpreting a script then the line
>> where the error occurred is signaled.
>
> Testing on Windows, it fails the first tests I try :-(
>
> select * from missing_table
>
> I get no error message at all. If I enter garbage, I just get the following:
>
> 1.0: syntax error, unexpected character
>
> If I enter this example from the docs:
>
> SET @A = INTEGER(100, 200);
> PRINT @A; -- Prints an integer between 100 and 200
> PRINT @A; -- Prints another integer between 100 and 200
>
> I get:
>
> 3.9-10: syntax error, unexpected '-'
>
> I would expect an error message from the first query, and nicely
> formatted errors from the second and third tests (though actually I
> wouldn't expect an error at all from the docs example). FWIW, other
> (non-erroring) examples work fine:
>
> SET @PROGR@M#TITLE = 'pgScript';
> PRINT '';
> PRINT @PROGR@M#TITLE + ' features:';
> PRINT '';
> PRINT '  * Regular PostgreSQL commands';
> PRINT '  * Control-of-flow language';
> PRINT '  * Local variables';
> PRINT '  * Random data generators';
>
> gives:
>
> [PGSCRIPT ]
> [PGSCRIPT ] pgScript features:
> [PGSCRIPT ]
> [PGSCRIPT ]   * Regular PostgreSQL commands
> [PGSCRIPT ]   * Control-of-flow language
> [PGSCRIPT ]   * Local variables
> [PGSCRIPT ]   * Random data generators
>
> and
>
> DECLARE @I, @T; -- Variable names begin with a @
> SET @I = 0; -- @I is an integer
> WHILE @I < 20
> BEGIN
>    SET @T = 'table' + CAST (@I AS STRING); -- Casts @I
>    CREATE TABLE @T (id integer primary key, data text);
>
>    SET @I = @I + 1;
> END
>
> Outputs the queries and resulting notices as expected.
>
> --
> Dave Page
> EnterpriseDB UK:   http://www.enterprisedb.com
>



--
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

2009/3/11 Dave Page <dpage@pgadmin.org>:
> Testing on Windows, it fails the first tests I try :-(
>
> select * from missing_table
>
> I get no error message at all. If I enter garbage, I just get the following:
>
> 1.0: syntax error, unexpected character

This is normal: you do not have anything in the output because the
query must be terminated with a semi-colon.
I will look at that and add an error message.
Add the semi-colon ";" and the query will be executed. An erroneous
query (like this one where the table does not exist) is valid from the
pgScript point of view. It returns a warning saying why the query did
not work but does not stop. I wanted to do like this because sometimes
with pgScript I test invalid queries and I do not want the script to
be stopped.

> If I enter this example from the docs:
>
> SET @A = INTEGER(100, 200);
> PRINT @A; -- Prints an integer between 100 and 200
> PRINT @A; -- Prints another integer between 100 and 200
>
> I get:
>
> 3.9-10: syntax error, unexpected '-'

Add an empty line at the end and the error will go away. This is the
way pgScript detects comments: the regular expression doing that is
"--".*$. I need to see if I can add "End of file" is addition to "$".

> I would expect an error message from the first query, and nicely
> formatted errors from the second and third tests (though actually I
> wouldn't expect an error at all from the docs example). FWIW, other
> (non-erroring) examples work fine:

I need to check whether I can modify how Bison outputs errors in case
a parsing error occurs.

> SET @PROGR@M#TITLE = 'pgScript';
> PRINT '';
> PRINT @PROGR@M#TITLE + ' features:';
> PRINT '';
> PRINT '  * Regular PostgreSQL commands';
> PRINT '  * Control-of-flow language';
> PRINT '  * Local variables';
> PRINT '  * Random data generators';
>
> gives:
>
> [PGSCRIPT ]
> [PGSCRIPT ] pgScript features:
> [PGSCRIPT ]
> [PGSCRIPT ]   * Regular PostgreSQL commands
> [PGSCRIPT ]   * Control-of-flow language
> [PGSCRIPT ]   * Local variables
> [PGSCRIPT ]   * Random data generators
>
> and
>
> DECLARE @I, @T; -- Variable names begin with a @
> SET @I = 0; -- @I is an integer
> WHILE @I < 20
> BEGIN
>    SET @T = 'table' + CAST (@I AS STRING); -- Casts @I
>    CREATE TABLE @T (id integer primary key, data text);
>
>    SET @I = @I + 1;
> END
>
> Outputs the queries and resulting notices as expected.
>

The problem you mentioned are things to improve but they have always
been there and not linked to a recent patch.

Best regards,
Mickael

2009/3/11 Dave Page <dpage@pgadmin.org>:
> I would expect an error message from the first query, and nicely
> formatted errors from the second and third tests (though actually I
> wouldn't expect an error at all from the docs example). FWIW, other
> (non-erroring) examples work fine:

Attached to this email, a patch that makes parsing error outputs nicer.

Best regards,
Mickael

2009/3/11 Dave Page <dpage@pgadmin.org>:
> If I enter this example from the docs:
>
> SET @A = INTEGER(100, 200);
> PRINT @A; -- Prints an integer between 100 and 200
> PRINT @A; -- Prints another integer between 100 and 200
>
> I get:
>
> 3.9-10: syntax error, unexpected '-'

Please refer to my previous message for the explanation of this syntax
error. A very simple correction is possible but I need the third patch
on my first email to be applied because the correction is on that part
of code (the idea is to add a wxT("\n") to the query when calling
psgScript->ParseString() in froQuery.cpp so that the script always
ends with an empty line).

Best regards,
Mickael

On Wed, Mar 11, 2009 at 5:51 PM, Mickael Deloison <mdeloison@gmail.com> wrote:
> 2009/3/11 Dave Page <dpage@pgadmin.org>:
>> Testing on Windows, it fails the first tests I try :-(
>>
>> select * from missing_table
>>
>> I get no error message at all. If I enter garbage, I just get the following:
>>
>> 1.0: syntax error, unexpected character
>
> This is normal: you do not have anything in the output because the
> query must be terminated with a semi-colon.
> I will look at that and add an error message.

Thanks - I think that would quickly become a gotcha otherwise!

> Add the semi-colon ";" and the query will be executed. An erroneous
> query (like this one where the table does not exist) is valid from the
> pgScript point of view. It returns a warning saying why the query did
> not work but does not stop. I wanted to do like this because sometimes
> with pgScript I test invalid queries and I do not want the script to
> be stopped.

OK.

> Add an empty line at the end and the error will go away. This is the
> way pgScript detects comments: the regular expression doing that is
> "--".*$. I need to see if I can add "End of file" is addition to "$".

Urgh.

>
> The problem you mentioned are things to improve but they have always
> been there and not linked to a recent patch.

OK, cool. I've committed the patch.

Thanks!

--
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

On Wed, Mar 11, 2009 at 7:11 PM, Mickael Deloison <mdeloison@gmail.com> wrote:
> 2009/3/11 Dave Page <dpage@pgadmin.org>:
>> I would expect an error message from the first query, and nicely
>> formatted errors from the second and third tests (though actually I
>> wouldn't expect an error at all from the docs example). FWIW, other
>> (non-erroring) examples work fine:
>
> Attached to this email, a patch that makes parsing error outputs nicer.

Yeah, that looks nicer - applied.

BTW, there's no need to tar.gz the patches unless they're over 100KB
or whatever the list limit is (and this list shouldn't auto-reject any
that are oversized like the other PG lists).

--
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

On Wed, Mar 11, 2009 at 7:23 PM, Mickael Deloison <mdeloison@gmail.com> wrote:

> Please refer to my previous message for the explanation of this syntax
> error. A very simple correction is possible but I need the third patch
> on my first email to be applied because the correction is on that part
> of code (the idea is to add a wxT("\n") to the query when calling
> psgScript->ParseString() in froQuery.cpp so that the script always
> ends with an empty line).

Ah - neat hack. I've implemented it and committed, so no need for a patch.

Thanks.

--
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com

2009/3/11 Dave Page <dpage@pgadmin.org>:
> On Wed, Mar 11, 2009 at 5:51 PM, Mickael Deloison <mdeloison@gmail.com> wrote:
>> 2009/3/11 Dave Page <dpage@pgadmin.org>:
>>> Testing on Windows, it fails the first tests I try :-(
>>>
>>> select * from missing_table
>>>
>>> I get no error message at all. If I enter garbage, I just get the following:
>>>
>>> 1.0: syntax error, unexpected character
>>
>> This is normal: you do not have anything in the output because the
>> query must be terminated with a semi-colon.
>> I will look at that and add an error message.
>
> Thanks - I think that would quickly become a gotcha otherwise!

Hi Dave,

Attached to this email, a patch that prints an error when statements
are not ended with a semi-colon or when the end of file in encountered
whereas a string is not ended. For example
SELECT 1
PRINT 'Hi
SELECT $A$ abc
SELECT 'Hi
All those statements return an error saying a semi-colon is expected.

Best regards,
Mickael

On Thu, Mar 12, 2009 at 1:56 PM, Mickael Deloison <mdeloison@gmail.com> wrote:

> Hi Dave,
>
> Attached to this email, a patch that prints an error when statements
> are not ended with a semi-colon or when the end of file in encountered
> whereas a string is not ended. For example
> SELECT 1
> PRINT 'Hi
> SELECT $A$ abc
> SELECT 'Hi
> All those statements return an error saying a semi-colon is expected.

Cool - thanks Mickael - patch applied.

--
Dave Page
EnterpriseDB UK:   http://www.enterprisedb.com