Howdy,
Very excited about the new `DO` command in 8.5a2. I read through the
patch review thread and found that, like me, Dim had expected it to
behave more like a lambda than a simple command. And from Tom's
comments, it looks like it was committed in such a way to make such
extensions
Howdy,
Very excited about the new `DO` command in 8.5a2. I read through the
patch review thread and found that, like me, Dim had expected it to
behave more like a lambda than a simple command. And from Tom's
comments, it looks like it was committed in such a way to make such
extensions
David E. Wheeler wrote:
Howdy,
Very excited about the new `DO` command in 8.5a2. I read through the
patch review thread and found that, like me, Dim had expected it to
behave more like a lambda than a simple command. And from Tom's
comments, it looks like it was committed in such a way to
Hello
I have a idea about migration of outer (psql) variables, and custom
shell variables.
some like:
psql --allow_custom_variables --table_name=mytable
inside psql we should to use :table_name variable with mytable as content.
then we can use syntax
do (table_name varchar) $$
begin
raise
Andrew Dunstan and...@dunslane.net writes:
David E. Wheeler wrote:
Very excited about the new `DO` command in 8.5a2. I read through the
patch review thread and found that, like me, Dim had expected it to
behave more like a lambda than a simple command.
It was discussed and rejected, at
On Oct 26, 2009, at 1:16 PM, Pavel Stehule wrote:
I have a idea about migration of outer (psql) variables, and custom
shell variables.
some like:
psql --allow_custom_variables --table_name=mytable
inside psql we should to use :table_name variable with mytable as
content.
then we can use
On Oct 26, 2009, at 1:21 PM, Tom Lane wrote:
A lambda facility would require being able to pass arguments and
return
results, which we intentionally left out of DO to keep it simple. By
the time you add all that notation, it's far from clear that you
shouldn't just define a function.
Well
2009/10/26 David E. Wheeler da...@kineticode.com:
On Oct 26, 2009, at 1:16 PM, Pavel Stehule wrote:
I have a idea about migration of outer (psql) variables, and custom
shell variables.
some like:
psql --allow_custom_variables --table_name=mytable
inside psql we should to use :table_name
On Oct 26, 2009, at 2:12 PM, Pavel Stehule wrote:
it should be light relation. 'DO' should be parametrised, and psql can
use own variables as 'DO' parameters.
I see, because `DO` is a statement, not an expression. Thus arguments
don't really make much sense (I wish it was an expression!).
David E. Wheeler wrote:
On Oct 26, 2009, at 2:12 PM, Pavel Stehule wrote:
it should be light relation. 'DO' should be parametrised, and psql can
use own variables as 'DO' parameters.
I see, because `DO` is a statement, not an expression. Thus arguments
don't really make much sense (I wish
2009/10/26 David E. Wheeler da...@kineticode.com:
On Oct 26, 2009, at 2:12 PM, Pavel Stehule wrote:
it should be light relation. 'DO' should be parametrised, and psql can
use own variables as 'DO' parameters.
I see, because `DO` is a statement, not an expression. Thus arguments don't
really
Pavel Stehule wrote:
2009/10/26 David E. Wheeler da...@kineticode.com:
On Oct 26, 2009, at 2:12 PM, Pavel Stehule wrote:
it should be light relation. 'DO' should be parametrised, and psql can
use own variables as 'DO' parameters.
I see, because `DO` is a statement, not an
Petr Jelinek pjmo...@pjmodos.net writes:
Tom Lane napsal(a):
The do.sgml file was missing from both your submissions, so I cooked
up a very quick-and-dirty reference page. It could stand to be fleshed
out a bit, probably. If there's useful material in your original,
please submit a followon
Hi,
Dimitri Fontaine dfonta...@hi-media.com writes:
Patch applies cleanly and build cleanly too, basic examples are working
fine.
I've been reading through the code and am going to mark it as ready for
commiter, as only remarks I have are probably because I do not know
enough about PostgreSQL
Dimitri Fontaine napsal(a):
Hi,
Dimitri Fontaine dfonta...@hi-media.com writes:
Patch applies cleanly and build cleanly too, basic examples are working
fine.
I've been reading through the code and am going to mark it as ready for
commiter, as only remarks I have are probably because
Petr Jelinek pjmo...@pjmodos.net writes:
It is. I attached patch which does not have this part.
do.sgml seems missing?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
I'm going through the anonymous-code-blocks patch now. There are some
things missing, notably the ability to create a language with an
anonymous-code-block handler. The only way you can do it is to have
a pg_pltemplate entry, which is certainly not good enough for languages
not distributed with
On Sat, Sep 19, 2009 at 8:23 PM, Andrew Dunstan and...@dunslane.net wrote:
Dimitri Fontaine wrote:
So here are the major points about this patch:
- it's missing the returns declaration syntax (default value could be
returns void?)
- it would be much more friendly to users if it had a
On Tue, Sep 22, 2009 at 1:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm going through the anonymous-code-blocks patch now. There are some
things missing, notably the ability to create a language with an
anonymous-code-block handler. The only way you can do it is to have
a pg_pltemplate
On Tue, Sep 22, 2009 at 01:50:45PM -0400, Robert Haas wrote:
On Tue, Sep 22, 2009 at 1:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I'm going through the anonymous-code-blocks patch now. There are
some things missing, notably the ability to create a language with
an anonymous-code-block
Tom Lane wrote:
I'm going through the anonymous-code-blocks patch now. There are some
things missing, notably the ability to create a language with an
anonymous-code-block handler. The only way you can do it is to have
a pg_pltemplate entry, which is certainly not good enough for languages
Robert Haas robertmh...@gmail.com writes:
Should we consider another generic options syntax, while we're on a
roll? In the long run, that's the best way to avoid having a zillion
keywords.
If there were any near-term prospect of more options for languages,
I might agree ... but there isn't,
Merlin Moncure mmonc...@gmail.com writes:
A note about void returning functionsthere are no send/recv
functions for the void type which will cause problems for users of
this feature over the binary protocol.
This isn't a SELECT and doesn't return anything, so I don't see the
issue.
Tom Lane t...@sss.pgh.pa.us writes:
Merlin Moncure mmonc...@gmail.com writes:
A note about void returning functionsthere are no send/recv
functions for the void type which will cause problems for users of
this feature over the binary protocol.
This isn't a SELECT and doesn't return
Petr Jelinek pjmo...@pjmodos.net writes:
[ anonymous code blocks patch ]
I committed this after some editorialization. Aside from adding missing
CREATE LANGUAGE and pg_dump support, I didn't like the API for inline
handler functions. Passing just a C string doesn't allow for any future
Tom Lane napsal(a):
Petr Jelinek pjmo...@pjmodos.net writes:
[ anonymous code blocks patch ]
I committed this after some editorialization. Aside from adding missing
CREATE LANGUAGE and pg_dump support, I didn't like the API for inline
handler functions. Passing just a C string
Hi,
Tom Lane t...@sss.pgh.pa.us writes:
Andrew Dunstan and...@dunslane.net writes:
Really? That wasn't my expectation at all. I expected that the code
would in effect be always returning void. I think you're moving the
goalposts a bit here. I don't think we need a RETURNS clause on it for
Robert Haas robertmh...@gmail.com writes:
That doesn't seem appropriate. Returned With Feedback means that the
patch is dead as far as this CommitFest goes, which isn't what you
seem to be saying at all. I think this should stay Needs Review until
it's had a full review, and then we can
2009/9/20 Dimitri Fontaine dfonta...@hi-media.com:
Hi,
Tom Lane t...@sss.pgh.pa.us writes:
Andrew Dunstan and...@dunslane.net writes:
Really? That wasn't my expectation at all. I expected that the code
would in effect be always returning void. I think you're moving the
goalposts a bit here.
Hi,
Petr Jelinek pjmo...@pjmodos.net writes:
I attached current version of the patch. I don't expect this to get
committed or anything, but I'd like other eyes to take a look at it.
I'm reviewing this patch, and have early questions that might allow for
a quick returned with little feedback
Dimitri Fontaine wrote:
So here are the major points about this patch:
- it's missing the returns declaration syntax (default value could be
returns void?)
- it would be much more friendly to users if it had a default output
for queries, the returned object seems a good fit
Andrew Dunstan and...@dunslane.net writes:
Dimitri Fontaine wrote:
So here are the major points about this patch:
- it's missing the returns declaration syntax (default value could be
returns void?)
- it would be much more friendly to users if it had a default output
for queries, the
Tom Lane napsal(a):
Andrew Dunstan and...@dunslane.net writes:
Dimitri Fontaine wrote:
So here are the major points about this patch:
- it's missing the returns declaration syntax (default value could be
returns void?)
- it would be much more friendly to users if it had a default
On Sat, Sep 19, 2009 at 8:03 PM, Dimitri Fontaine
dfonta...@hi-media.com wrote:
PS: I'll go mark as returned with feedback but intend to complete this
review in the following days, by having a look at the code and
documentation. Unless beaten to it, as I won't be able to give accurate
guidance
34 matches
Mail list logo
