The SQL standard requires conforming implementations to provide an
"SQL flagger" facility that, in its simplest form (which is the only
required one), points out when SQL syntax features that are not in the
core SQL feature set are used.  (No catalog lookup is required.)  In
other words, it prints a warning when you use extension features.
This feature would probably be useful for users who have little
awareness of standard SQL, and those who want to use PostgreSQL as a
development platform for portable applications.

I think we could implement this with relatively little intrusion if we
create an interface routine, say SQLFlagger(), which takes the entire
parsetree as its argument can then analyze the syntax in as much
detail as it likes.  (Of course that function would only be called if
a certain Boolean flag is set.)  But a few syntax elements would need
to checked right within gram.y, such as the omission of the drop
behavior or the use of TEMP vs. TEMPORARY, which is resolved right in
the parser and cannot be detected later.

Should we implement this?

-- 
Peter Eisentraut   peter_e@gmx.net


Sun, 12 Jan 2003 19:26:48 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
SQL flagger
Peter Eisentraut <peter_e@gmx.net> writes:
> The SQL standard requires conforming implementations to provide an
> "SQL flagger" facility ...

> I think we could implement this with relatively little intrusion if we
> create an interface routine, say SQLFlagger(), which takes the entire
> parsetree as its argument can then analyze the syntax in as much
> detail as it likes.  (Of course that function would only be called if
> a certain Boolean flag is set.)  But a few syntax elements would need
> to checked right within gram.y, such as the omission of the drop
> behavior or the use of TEMP vs. TEMPORARY, which is resolved right in
> the parser and cannot be detected later.

> Should we implement this?

I think we would be better off to implement this as a standalone program
rather than as a backend mode option.

In general, gram.y's behavior should never depend on any runtime
variables.  If it does, you get inconsistent results from
	SET var = val ; ... other stuff ...
(one query string) compared to
	SET var = val
	... other stuff ...
(two query strings), because the whole query string is fed through
gram.y before any of it is executed.

Plan B, if you really want to do this in the backend, would be to alter
gram.y's output trees so that all the non-spec constructs are still
recognizable in the raw parse tree, and any conversions needed are done
in analyze.c's processing (which would also be the place to issue the
flagger warnings).  This is not necessarily a bad idea; I've always
thought that we do too much work in gram.y anyway.  But you will be
fighting a permanent rear-guard action to keep people from
re-introducing variant syntaxes by quick gram.y hacks.

In general I like the idea of a standalone program better, however.
It would be able to have its own grammar tuned to its needs.  I don't
think there would be much maintenance problem introduced thereby,
since presumably the flagger's grammar is driven by the spec and won't
need to change when we change what Postgres accepts.

			regards, tom lane

Sun, 12 Jan 2003 13:56:28 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: SQL flagger 
THe SQL Flagger is only required for Intermediate SQL.  SQL'92 23.4 says Entry 
SQL may, but are not required to.

This said, it is a nice to have feature for the reasons that Peter pointed out.

But as I understand it, this is a sort of warning feature, and depending on the 
"extent of checking" option may be just something that the parser itself detects 
(Sysntax only) or something we detect in the analyzer code (catalog lookup). 
The second one has security issues (the standard suggests using a specific 
Information Schema) so we may want to avoid it for now.

Basically we would issue a FLAGGER message, if "level of flagging" is set to 
"Entry SQL Flagging" every time the parser finds a clause that is not Entry SQL. 
  Similarly for non Intermediate SQL constructs if level is "Intermediate SQL 
Flagging". We would, of course, issue a FLAGGER message for all our PostgreSQL 
specific extensions in any level (if Flagging enabled).

If I understood it correctly, we only need a new elog level and add a few elog 
calls in some of gram.y clauses...

Regards,
Fernando

Tom Lane wrote:> Peter Eisentraut <peter_e@gmx.net> writes:
> 
>>The SQL standard requires conforming implementations to provide an
>>"SQL flagger" facility ...
> 
> 
>>I think we could implement this with relatively little intrusion if we
>>create an interface routine, say SQLFlagger(), which takes the entire
>>parsetree as its argument can then analyze the syntax in as much
>>detail as it likes.  (Of course that function would only be called if
>>a certain Boolean flag is set.)  But a few syntax elements would need
>>to checked right within gram.y, such as the omission of the drop
>>behavior or the use of TEMP vs. TEMPORARY, which is resolved right in
>>the parser and cannot be detected later.
> 
> 
>>Should we implement this?
> 
> 
> I think we would be better off to implement this as a standalone program
> rather than as a backend mode option.
> 
> In general, gram.y's behavior should never depend on any runtime
> variables.  If it does, you get inconsistent results from
> 	SET var = val ; ... other stuff ...
> (one query string) compared to
> 	SET var = val
> 	... other stuff ...
> (two query strings), because the whole query string is fed through
> gram.y before any of it is executed.
> 
> Plan B, if you really want to do this in the backend, would be to alter
> gram.y's output trees so that all the non-spec constructs are still
> recognizable in the raw parse tree, and any conversions needed are done
> in analyze.c's processing (which would also be the place to issue the
> flagger warnings).  This is not necessarily a bad idea; I've always
> thought that we do too much work in gram.y anyway.  But you will be
> fighting a permanent rear-guard action to keep people from
> re-introducing variant syntaxes by quick gram.y hacks.
> 
> In general I like the idea of a standalone program better, however.
> It would be able to have its own grammar tuned to its needs.  I don't
> think there would be much maintenance problem introduced thereby,
> since presumably the flagger's grammar is driven by the spec and won't
> need to change when we change what Postgres accepts.
> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
> 



-- 
Fernando Nasser
Red Hat - Toronto                       E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9


Wed, 15 Jan 2003 12:52:28 -0500
Fernando Nasser <fnasser@redhat.com>
Re: SQL flagger
Fernando Nasser writes:

> THe SQL Flagger is only required for Intermediate SQL.  SQL'92 23.4 says Entry
> SQL may, but are not required to.

SQL 92 is obsolete.  In SQL 99 and later it's a core feature.

> If I understood it correctly, we only need a new elog level and add a few elog
> calls in some of gram.y clauses...

As was already mentioned, you cannot evaluate run-time parameters (which
the flagger would be) in gram.y because of some transaction issues.  You
need to do it in the analyze phase after the parser.

"A few" is also an optimistic statement.  While the majority of the
utility commands can be rejected outright, getting the details right to a
usable degree on the rest is tricky.

-- 
Peter Eisentraut   peter_e@gmx.net


Thu, 16 Jan 2003 00:44:14 +0100 (CET)
Peter Eisentraut <peter_e@gmx.net>
Re: SQL flagger