Neil Conway <[EMAIL PROTECTED]> writes:
> On Fri, 2004-09-17 at 00:34, Tom Lane wrote:
>> I think Andrew has a point: why aren't they the same issue?
> (Note that we need to support CALL proc(...); in SQL for standards
> compliance in any event.)
Right. I'm thinking we could effectively make the
On Fri, 2004-09-17 at 00:34, Tom Lane wrote:
> I think Andrew has a point: why aren't they the same issue? It would
> certainly be no harder to support
> func( ... );
> as a SQL statement than as something allowed only in plpgsql.
If there's a consensus that it is better to modify the main
Neil Conway <[EMAIL PROTECTED]> writes:
> On Thu, 2004-09-16 at 01:19, Andrew Dunstan wrote:
>> ISTM that this is being done at the wrong level anyway.
> I think these are two distinct issues.
I think Andrew has a point: why aren't they the same issue? It would
certainly be no harder to support
On Thu, 16 Sep 2004, Greg Stark wrote:
>
> Neil Conway <[EMAIL PROTECTED]> writes:
>
> > whereas adding support for CALL to SQL is part of proper support for stored
> > procedures. Gavin and I are hoping to send a proposal for the latter to
> > -hackers in a few days.
>
> What is the point of stor
Neil Conway <[EMAIL PROTECTED]> writes:
> whereas adding support for CALL to SQL is part of proper support for stored
> procedures. Gavin and I are hoping to send a proposal for the latter to
> -hackers in a few days.
What is the point of stored procedures being distinct from functions anyways?
On Thu, 2004-09-16 at 01:19, Andrew Dunstan wrote:
> ISTM that this is being done at the wrong level anyway. I'd like to see
> a facility available in our SQL, e.g.
>
> CALL foo();
>
> with the restriction that foo() should be declared to return void.
I think these are two distinct issues. Th
On Thu, 2004-09-16 at 01:05, Tom Lane wrote:
> That seems fairly unworkable. For example
>
> SELECT (2,3,4);
>
> is valid SQL.
Good point. The disambiguation algorithm I suggested isn't sufficient,
but I think there ought to be _some_ reasonable algorithm.
>From glancing over the SQL com
Andrew Dunstan wrote:
ISTM that this is being done at the wrong level anyway. I'd like to see
a facility available in our SQL, e.g.
CALL foo();
with the restriction that foo() should be declared to return void. Of
course, that doesn't remove the keyword requirement as Neil wanted, but
doing th
Tom Lane wrote:
Neil Conway <[EMAIL PROTECTED]> writes:
(3) The parser must distinguish between two cases when it sees an
unknown word (T_WORD) beginning a statement. The word could be the
beginning of a SQL statement (stmt_execsql in the grammar), such as:
UPDATE ...;
or the na
Neil Conway <[EMAIL PROTECTED]> writes:
> (3) The parser must distinguish between two cases when it sees an
> unknown word (T_WORD) beginning a statement. The word could be the
> beginning of a SQL statement (stmt_execsql in the grammar), such as:
> UPDATE ...;
> or the name of a function in a fu
On Thu, 2004-09-16 at 00:06, Neil Conway wrote:
> Attached is a proof of concept patch that implements this.
Woops, the patch is really attached this time.
-Neil
Index: src/pl/plpgsql/src/gram.y
===
RCS file: /home/neilc/private-cvs
11 matches
Mail list logo
