Modification of proposal:
I think so from discussion can take some two points:
a) enhancing editing
\ef funcname, line ... edit function and move cursor on line
\ef... edit function - name and line take from
error message
b) enhancing view
\sf funcname ...
Dimitri Fontaine dfonta...@hi-media.com writes:
Sure, I should go and write a complete pgsql emacs mode
with a linum-mode like feature counting lines the way PG does it, …
Ok maybe just using the current SQL mode and linum mode is enough if we
teach this latter one to count PostgreSQL function
2010/3/22 Dimitri Fontaine dfonta...@hi-media.com:
Dimitri Fontaine dfonta...@hi-media.com writes:
Sure, I should go and write a complete pgsql emacs mode
with a linum-mode like feature counting lines the way PG does it, …
Ok maybe just using the current SQL mode and linum mode is enough if
On sön, 2010-03-21 at 20:40 -0400, Robert Haas wrote:
\ef function-name line-number
with suitable magic to get the editor to place the cursor at that line.
I suspect this wouldn't be too hard to do with emacs --- what do you
think about vi?
Well, in vi you can just do vi +linenum
On Mar 22, 2010, at 2:23 PM, Peter Eisentraut wrote:
On sön, 2010-03-21 at 20:40 -0400, Robert Haas wrote:
\ef function-name line-number
with suitable magic to get the editor to place the cursor at that line.
I suspect this wouldn't be too hard to do with emacs --- what do you
think
On 21/03/2010 8:03 PM, Pavel Stehule wrote:
Hello
Current form of function detail isn't too practical (see screenshot 1)
we can move source code to separate area (maybe we can add rownumbers)
see screenshot 2 (it is only mockup, real implementation can be more
inteligent in rows numbering)
2010/3/21 Craig Ringer cr...@postnewspapers.com.au:
On 21/03/2010 8:03 PM, Pavel Stehule wrote:
Hello
Current form of function detail isn't too practical (see screenshot 1)
we can move source code to separate area (maybe we can add rownumbers)
see screenshot 2 (it is only mockup, real
On 21/03/2010 10:33 PM, Pavel Stehule wrote:
2010/3/21 Craig Ringercr...@postnewspapers.com.au:
On 21/03/2010 8:03 PM, Pavel Stehule wrote:
Hello
Current form of function detail isn't too practical (see screenshot 1)
we can move source code to separate area (maybe we can add rownumbers)
2010/3/21 Craig Ringer cr...@postnewspapers.com.au:
On 21/03/2010 10:33 PM, Pavel Stehule wrote:
2010/3/21 Craig Ringercr...@postnewspapers.com.au:
On 21/03/2010 8:03 PM, Pavel Stehule wrote:
Hello
Current form of function detail isn't too practical (see screenshot 1)
we can move source
Pavel Stehule pavel.steh...@gmail.com writes:
I understanding. But this functionality is implemented yet. My
motivation is to design some tool for more easy searching n. row in
source code (for interpretation error messages) and possibility to see
this row in some context.
Why is this a good
2010/3/21 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com writes:
I understanding. But this functionality is implemented yet. My
motivation is to design some tool for more easy searching n. row in
source code (for interpretation error messages) and possibility to see
this
Tom Lane t...@sss.pgh.pa.us writes:
Why is this a good way to attack that? If you think the context already
provided in error messages isn't good enough, seems like the thing to do
is fix the error messages. Nobody is going to want to dump out a
multi-hundred-line function like this in order
Craig Ringer wrote:
On 21/03/2010 8:03 PM, Pavel Stehule wrote:
Hello
Current form of function detail isn't too practical (see screenshot 1)
we can move source code to separate area (maybe we can add rownumbers)
see screenshot 2 (it is only mockup, real implementation can be more
Dimitri Fontaine dfonta...@hi-media.com writes:
I'm not sure what better tool than what Pavel is proposing we already
have, though.
We have quite decent features for localizing syntax errors in functions, eg
regression=# create function foo(x int) returns int language plpgsql as $$
begin
Tom Lane t...@sss.pgh.pa.us writes:
ERROR: syntax error at end of input
LINE 3: return 1/;
^
What I think is called for is extending that approach to run-time
errors. plpgsql doesn't make any particular effort to provide that
right now, but it easily could IMO.
2010/3/21 Tom Lane t...@sss.pgh.pa.us:
Dimitri Fontaine dfonta...@hi-media.com writes:
I'm not sure what better tool than what Pavel is proposing we already
have, though.
We have quite decent features for localizing syntax errors in functions, eg
regression=# create function foo(x int)
On Sun, Mar 21, 2010 at 11:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
I understanding. But this functionality is implemented yet. My
motivation is to design some tool for more easy searching n. row in
source code (for interpretation error messages)
Robert Haas robertmh...@gmail.com writes:
I'm not sure that Pavel's idea is the right way to attack the problem,
but I don't agree with this either. Line numbers are really the only
feasible way of identifying a position in a large function. I usually
bring up the function source code in vi
On Sun, Mar 21, 2010 at 4:35 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I'm not sure that Pavel's idea is the right way to attack the problem,
but I don't agree with this either. Line numbers are really the only
feasible way of identifying a position in a
2010/3/21 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
I'm not sure that Pavel's idea is the right way to attack the problem,
but I don't agree with this either. Line numbers are really the only
feasible way of identifying a position in a large function. I usually
The direction that we ought to be pushing in, I think, is the same as
the vision for syntax error handling: enable pgAdmin and similar tools
to pop up the function text with a cursor placed at (more or less) the
right place. It's interesting to think about how that might be extended
to
21 matches
Mail list logo
