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 ... show
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
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 "v
2010/3/22 Dimitri Fontaine :
> Dimitri Fontaine 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 Pos
Dimitri Fontaine 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 lines the same way as
>
> 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
2010/3/21 Tom Lane :
> Robert Haas 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 co
On Sun, Mar 21, 2010 at 4:35 PM, Tom Lane wrote:
> Robert Haas 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
>> br
Robert Haas 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 and then use j wit
On Sun, Mar 21, 2010 at 11:42 AM, Tom Lane wrote:
> Pavel Stehule 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
2010/3/21 Tom Lane :
> Dimitri Fontaine 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 $$
>
Tom Lane 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. Pavel's proposal is
Dimitri Fontaine 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
return 1/;
end$$;
ERROR:
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
inteligent
Tom Lane 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 to identify wh
2010/3/21 Tom Lane :
> Pavel Stehule 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 th
Pavel Stehule 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 way to attack that?
2010/3/21 Craig Ringer :
> On 21/03/2010 10:33 PM, Pavel Stehule wrote:
>>
>> 2010/3/21 Craig Ringer:
>>>
>>> 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 ar
On 21/03/2010 10:33 PM, Pavel Stehule wrote:
2010/3/21 Craig Ringer:
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 m
2010/3/21 Craig Ringer :
> 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
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)
I
21 matches
Mail list logo
