Hello All,
This patch implements a (generic) callback functionality in the parser.
The mechanism can be used to send callback messages from within the parser
to external functions.
I would like to know your opinion about the following:
In previous discussion Tom referred to:
One point here is
On Sat, Nov 03, 2007 at 12:36:45PM +0100, Gevik Babakhani wrote:
Hello All,
This patch implements a (generic) callback functionality in the parser.
The mechanism can be used to send callback messages from within the parser
to external functions.
I would like to know your opinion about the
Any thoughts?
I think a prefix of ':' would be good, as it's already a standard,
kinda. Anybody who names a database object :foo deserves whatever
happens to them :P
Cheers,
David.
+1
':' is shorter than 'this'. And ':' is well known in SQL area.
Pavel
David Fetter [EMAIL PROTECTED] writes:
I think a prefix of ':' would be good, as it's already a standard,
kinda. Anybody who names a database object :foo deserves whatever
happens to them :P
The important word there is kinda. We do not need a prefix and
I'll resist introducing one.
I think a prefix of ':' would be good, as it's already a
standard, kinda. Anybody who names a database object :foo
deserves whatever happens to them :P
I for one like something less cryptic than ':'
besids going with ':' means extra hack in gram.y
(Ones we get to implement packages I
On Sat, Nov 03, 2007 at 12:44:07PM -0400, Tom Lane wrote:
David Fetter [EMAIL PROTECTED] writes:
I think a prefix of ':' would be good, as it's already a standard,
kinda. Anybody who names a database object :foo deserves whatever
happens to them :P
The important word there is kinda. We
David Fetter [EMAIL PROTECTED] writes:
What I mean by kinda is that it's a standard way of handling
parameters in Oracle and in DBI.
That's a good reason *not* to use them for other purposes. Users trying to
create procedures through DBI or other interfaces like it will run into
problems
So where do we go from here?
a. function name.arg name
b. this.arg name
c. ':'argname
d. just argname
option a,b and d are easy to implement.
option d would be least clear and readable considering
sql functions can be long and have multiple arguments.
option c is more difficult because gram.y
David Fetter [EMAIL PROTECTED] writes:
What I mean by kinda is that it's a standard way of handling
parameters in Oracle and in DBI. I think it would be a very bad idea
to require that people use the function name in parameters, as such
names can be quite long. People using names like :foo
Gevik Babakhani [EMAIL PROTECTED] writes:
So where do we go from here?
a. function name.arg name
b. this.arg name
c. ':'argname
d. just argname
We must support both a and d.
regards, tom lane
---(end of broadcast)---
Gevik Babakhani [EMAIL PROTECTED] writes:
So where do we go from here?
a. function name.arg name
b. this.arg name
c. ':'argname
d. just argname
We must support both a and d.
Then a and d it is :)
Regards,
Gevik
Gevik Babakhani
This has been saved for the 8.4 release:
http://momjian.postgresql.org/cgi-bin/pgpatches_hold
---
Brendan Jurd wrote:
As discussed on -hackers, I'm trying to get rid of some redundant code
by creating a widely
12 matches
Mail list logo
