David Fetter da...@fetter.org wrote:
DO { [ LANGUAGE lang_name ] | code } ...
Good catch :)
The tab completion patch and documentation fix were committed.
Thanks.
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center
--
Sent via pgsql-hackers mailing list
On Wed, Feb 10, 2010 at 11:00:00AM +0900, Takahiro Itagaki wrote:
Bruce Momjian br...@momjian.us wrote:
Where are we on this patch? We should at least implement the completion
for 'LANGUAGE' in 'DO', and use the existing pg_language query for
completion. I am attaching a patch that does
David Fetter da...@fetter.org wrote:
Syntax of DO command is:
DO code [ LANGUAGE lang_name ]
That's not the only syntax.
DO [LANGUAGE lang_name] code
also works, e.g.:
Hmmm, but we mention only above syntax in the documentation.
Takahiro Itagaki escreveu:
Should we fix the documentation when we add the tab completion?
Yes, it seems consistent with other commands having optional parameters in the
middle of the command rather than at the end.
--
Euler Taveira de Oliveira
http://www.timbira.com/
--
Sent via
On Fri, Feb 12, 2010 at 09:24:55AM +0900, Takahiro Itagaki wrote:
David Fetter da...@fetter.org wrote:
Syntax of DO command is:
DO code [ LANGUAGE lang_name ]
That's not the only syntax.
DO [LANGUAGE lang_name] code
also works, e.g.:
Hmmm, but we mention only above
On Thu, Feb 11, 2010 at 11:26:10PM -0200, Euler Taveira de Oliveira wrote:
Takahiro Itagaki escreveu:
Should we fix the documentation when we add the tab completion?
Yes, it seems consistent with other commands having optional
parameters in the middle of the command rather than at the end.
David Fetter escreveu:
It's consistent with how we do CREATE FUNCTION, where the order of
parameters after RETURNS is arbitrary.
If it is arbitrary the synopsis is wrong because it is imposing that code
should be written after DO. It should be:
DO { [ LANGUAGE lang_name ] | code } ...
--
On Fri, Feb 12, 2010 at 12:21:02AM -0200, Euler Taveira de Oliveira wrote:
David Fetter escreveu:
It's consistent with how we do CREATE FUNCTION, where the order of
parameters after RETURNS is arbitrary.
If it is arbitrary the synopsis is wrong because it is imposing that
code should be
Takahiro Itagaki wrote:
Bruce Momjian br...@momjian.us wrote:
Where are we on this patch? We should at least implement the completion
for 'LANGUAGE' in 'DO', and use the existing pg_language query for
completion. I am attaching a patch that does exactly this.
I don't think we need
Bruce Momjian br...@momjian.us wrote:
Where are we on this patch? We should at least implement the completion
for 'LANGUAGE' in 'DO', and use the existing pg_language query for
completion. I am attaching a patch that does exactly this.
I don't think we need the patch except adding DO to
Robert Haas wrote:
On Sat, Jan 2, 2010 at 7:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
On l?r, 2010-01-02 at 17:34 -0500, Tom Lane wrote:
As for the overhead, these queries are not zero-maintenance. ?I still
think that the usefulness of tab
On Sat, Jan 2, 2010 at 7:47 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Peter Eisentraut pete...@gmx.net writes:
On lör, 2010-01-02 at 17:34 -0500, Tom Lane wrote:
As for the overhead, these queries are not zero-maintenance. I still
think that the usefulness of tab completion here is pretty darn
Folks,
Please find enclosed a patch which adds tab completion for DO blocks.
Thanks to Andrew Gierth and Stefan Kaltenbrunner for help putting it
together :)
Cheers,
David.
--
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype:
David Fetter da...@fetter.org writes:
Please find enclosed a patch which adds tab completion for DO blocks.
Seems (a) rather pointless and (b) wrong in detail.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
On Sat, Jan 02, 2010 at 04:22:38PM -0500, Tom Lane wrote:
David Fetter da...@fetter.org writes:
Please find enclosed a patch which adds tab completion for DO
blocks.
Seems (a) rather pointless and
I don't find it so.
(b) wrong in detail.
How? That it can't look back past the code
David Fetter da...@fetter.org writes:
On Sat, Jan 02, 2010 at 04:22:38PM -0500, Tom Lane wrote:
(b) wrong in detail.
How?
It doesn't actually work, because the query isn't paying attention to
the current partial word. Try do language pltab, or just compare
source to the original
On Sat, Jan 02, 2010 at 04:53:45PM -0500, Tom Lane wrote:
David Fetter da...@fetter.org writes:
On Sat, Jan 02, 2010 at 04:22:38PM -0500, Tom Lane wrote:
(b) wrong in detail.
How?
It doesn't actually work, because the query isn't paying attention to
the current partial word. Try do
David Fetter da...@fetter.org writes:
It doesn't actually work, because the query isn't paying attention to
the current partial word. Try do language pltab, or just compare
source to the original Query_for_list_of_languages.
Thanks for the heads-up. New patch attached :)
My inclination is
On Sat, Jan 02, 2010 at 05:10:08PM -0500, Tom Lane wrote:
David Fetter da...@fetter.org writes:
It doesn't actually work, because the query isn't paying attention to
the current partial word. Try do language pltab, or just compare
source to the original Query_for_list_of_languages.
David Fetter da...@fetter.org writes:
My inclination is to not have the separate query at all,
I made one so people couldn't tab complete themselves an unpleasant
surprise. The overhead doesn't seem huge.
What unpleasant surprise is that going to be? They'll get an error
message telling
On lör, 2010-01-02 at 17:34 -0500, Tom Lane wrote:
As for the overhead, these queries are not zero-maintenance. I still
think that the usefulness of tab completion here is pretty darn
minimal,
since most people are more likely to rely on default_do_language;
We really don't have any data on
Peter Eisentraut pete...@gmx.net writes:
On lör, 2010-01-02 at 17:34 -0500, Tom Lane wrote:
As for the overhead, these queries are not zero-maintenance. I still
think that the usefulness of tab completion here is pretty darn
minimal,
since most people are more likely to rely on
22 matches
Mail list logo
