Thread: proposal: more practical view on function's source code
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) Regards Pavel Stehule
Attachment
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) Ideally, the output of the source listing could be used as input to CREATE OR REPLACE FUNCTION without excessive massaging. Those line number prefixes make it hard to grab the output of \df+ and do something useful with it. Sure, vim's column-edit takes care of them quickly enough, but it's still a pain, and if the output format is to be changed it might be nice to see it change in a way that makes it easier to re-use that source listing. -- Craig Ringer
2010/3/21 Craig Ringer <craig@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 implementation can be more >> inteligent in rows numbering) > > Ideally, the output of the source listing could be used as input to CREATE > OR REPLACE FUNCTION without excessive massaging. Those line number prefixes > make it hard to grab the output of \df+ and do something useful with it. there is \ef statement now > Sure, vim's column-edit takes care of them quickly enough, but it's still a > pain, and if the output format is to be changed it might be nice to see it > change in a way that makes it easier to re-use that source listing. 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. maybe we can gently select an behave with last char in command \df+ standard output - numbered source code \dfd - show only source code (\ Detail Function Dump ) Regards Pavel > > -- > Craig Ringer >
On 21/03/2010 10:33 PM, Pavel Stehule wrote: > 2010/3/21 Craig Ringer<craig@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 implementation can be more >>> inteligent in rows numbering) >> >> Ideally, the output of the source listing could be used as input to CREATE >> OR REPLACE FUNCTION without excessive massaging. Those line number prefixes >> make it hard to grab the output of \df+ and do something useful with it. > > there is \ef statement now ... which I completely missed. My apologies; that problem is already solved. -- Craig Ringer
2010/3/21 Craig Ringer <craig@postnewspapers.com.au>: > On 21/03/2010 10:33 PM, Pavel Stehule wrote: >> >> 2010/3/21 Craig Ringer<craig@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 implementation can be more >>>> inteligent in rows numbering) >>> >>> Ideally, the output of the source listing could be used as input to >>> CREATE >>> OR REPLACE FUNCTION without excessive massaging. Those line number >>> prefixes >>> make it hard to grab the output of \df+ and do something useful with it. >> >> there is \ef statement now > > ... which I completely missed. My apologies; that problem is already solved. :) Pavel > > -- > Craig Ringer >
Pavel Stehule <pavel.stehule@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 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 which
statement is being fingered by an error.
regards, tom lane
2010/3/21 Tom Lane <tgl@sss.pgh.pa.us>: > Pavel Stehule <pavel.stehule@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 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 which > statement is being fingered by an error. I hope so it is good way. Sure, it is personal - somebody looking on error message and knows all - not me, and I hope so I am not the total lost person :). I dislike solution like gdb with showing n lines before and n lines after. And we cannot to use some external tools for line numbering, because line numbering in our PL languages is very specific (using line number in external editor can be confusing - I am old dog (not for me)). Not only for me is very difficult to identify row number from error message. I am sure, so this way is useless for multi-hundred-line function, but I hope so nobody write this functions (only one times I wrote very long procedure, because I could not to use a global variables). Optimum is about 60 lines still - and from my experience max is about 200 lines and don't forget - there is a pager. Regards Pavel Stehule > > regards, tom lane >
Tom Lane <tgl@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 to identify which > statement is being fingered by an error. Well that's true in that I've often counted lines myself for short enough procedures, and as soon as they too long I just add lots of RAISE NOTICE and build up a test-case etc. I'm not sure what better tool than what Pavel is proposing we already have, though. Sure, I should go and write a complete pgsql emacs mode with a linum-mode like feature counting lines the way PG does it, … But a simple \dfs for seeing the only the source, maybe with \dfs+ for seeing the line numbers too, would be a nice addition to psql in my view. Regards, -- dim
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 in rows numbering) > > Ideally, the output of the source listing could be used as input to > CREATE OR REPLACE FUNCTION without excessive massaging. Those line > number prefixes make it hard to grab the output of \df+ and do > something useful with it. Sure, vim's column-edit takes care of them > quickly enough, but it's still a pain, and if the output format is to > be changed it might be nice to see it change in a way that makes it > easier to re-use that source listing. You can get there sorta by doing "\pset format unaligned" followed by "\df+ funcname" But I agree it's annoying to have to do two commands. cheers andrew
Dimitri Fontaine <dfontaine@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 return 1/;
end$$;
ERROR: syntax error at end of input
LINE 3: return 1/; ^
regression=#
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 only of use to
people using psql, which is not everyone --- and it seems pretty awkward
to me even for psql users.
regards, tom lane
Tom Lane <tgl@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. Pavel's proposal is only of use to > people using psql, which is not everyone --- and it seems pretty awkward > to me even for psql users. Oh yes, that would be nice to have too :) -- dim
2010/3/21 Tom Lane <tgl@sss.pgh.pa.us>: > Dimitri Fontaine <dfontaine@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 > return 1/; > end$$; > ERROR: syntax error at end of input > LINE 3: return 1/; > ^ > regression=# > > 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 only of use to > people using psql, which is not everyone --- and it seems pretty awkward > to me even for psql users. yes - it is just for psql users. I manage some database where I can run only psql. I have to see some lines before and some lines after. It is one argument. second argument - current view is too wide, too long some general support can be included in core create or replace function pg_get_function_rows(oid) returns table(n int, src text) as $$ begin for src in select * from unnest(string_to_array(pg_get_functiondef($1),e'\n')) loop if src like '%$function$%' then return next; if n isnull then n := 1; else n = null; end if; else return next; n := n + 1; end if; end loop;return; end; $$ language plpgsql; CREATE FUNCTION Time: 236.426 ms postgres=# select * from pg_get_function_rows(16385); n │ src ───┼───────────────────────────────────────── │ CREATE OR REPLACE FUNCTION public.foo() │ RETURNS void │ LANGUAGE plpgsql │ AS $function$1 │ begin2 │ for i in 1..3 loop3 │ raise notice 'i=%', i/0;4 │ end loop;5 │ end;6 │ $function$ │ (11 rows) regards Pavel Stehule > > regards, tom lane >
On Sun, Mar 21, 2010 at 11:42 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Pavel Stehule <pavel.stehule@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 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 which > statement is being fingered by an error. 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 with a repeat count to find the offending line. It's not uncommon for me to have various places in the function that look somewhat similar, so expecting me to find the right place other than by the line number would not work very well for me. ...Robert
Robert Haas <robertmhaas@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 and then use j with a repeat
> count to find the offending line. It's not uncommon for me to have
> various places in the function that look somewhat similar, so
> expecting me to find the right place other than by the line number
> would not work very well for me.
I'm certainly not proposing removing the line number from error
messages. I'm just saying that I see no value in the proposed psql \df
change for this purpose.
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 lower-tech solutions like \ef. I could see telling people to type\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?
regards, tom lane
On Sun, Mar 21, 2010 at 4:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@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 and then use j with a repeat >> count to find the offending line. It's not uncommon for me to have >> various places in the function that look somewhat similar, so >> expecting me to find the right place other than by the line number >> would not work very well for me. > > I'm certainly not proposing removing the line number from error > messages. I'm just saying that I see no value in the proposed psql \df > change for this purpose. > > 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 lower-tech solutions like \ef. I could see telling people to type > \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 filename". ...Robert
2010/3/21 Tom Lane <tgl@sss.pgh.pa.us>: > Robert Haas <robertmhaas@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 and then use j with a repeat >> count to find the offending line. It's not uncommon for me to have >> various places in the function that look somewhat similar, so >> expecting me to find the right place other than by the line number >> would not work very well for me. > > I'm certainly not proposing removing the line number from error > messages. I'm just saying that I see no value in the proposed psql \df > change for this purpose. > > 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 lower-tech solutions like \ef. I could see telling people to type > \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? Uff, why? - almost of time you don't need, you must not edit directly code of procedures. - startup time of text processor - this function will start on some specific editor, but pg allows to set any external editor - it isn't effective - really (I think it is too much chars). I prefer two or three chars shortcut Pavel > > regards, tom lane >
> > 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 lower-tech solutions like \ef. I could see telling people to type > \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? > some thinking. This is other functionality and can be nice in psql too - but it can be more automatic - only \ef"E" without others parameters - like show line on last error - without writing function name, without writing line number - both information can be in error buffer. But you have to design universal mechanism for editor call with line number parameter (isn't big problem probably). And it's slower - you have to start second application. What about some hypotetical statement Show Function? \sf name -- show function \sf name, line -- show function from line Pavel > regards, tom lane >
Dimitri Fontaine <dfontaine@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 lines the same way as the server does. I think the attached just does that. With it activated in your emacs, M-x linum-mode on a sql-mode buffer will show two counts when in a function, first one is the function line number. Regards, -- dim
Attachment
2010/3/22 Dimitri Fontaine <dfontaine@hi-media.com>: > Dimitri Fontaine <dfontaine@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 lines the same way as > the server does. I think the attached just does that. > > With it activated in your emacs, M-x linum-mode on a sql-mode buffer > will show two counts when in a function, first one is the function line > number. great - I am looking somebody who can hack emacs sql-mode :). I'll have a few questions and request. Back to my problem - I dislike to start emacs every when I would to like source code ;) Pavel > > Regards, > -- > dim > >
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 filename". I think that's a pretty widely spread convention. A quick test shows that all of emacs, vi, joe, and nano support this. Of course there are editors that don't support it, so we'll have to distinguish that somehow, but it won't be too complicated to support a few of the common editors.
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 about vi? >> >> Well, in vi you can just do "vi +linenum filename". > > I think that's a pretty widely spread convention. A quick test shows > that all of emacs, vi, joe, and nano support this. Of course there are > editors that don't support it, so we'll have to distinguish that > somehow, but it won't be too complicated to support a few of the common > editors. Would an environment variable be the general purpose answer? Much the same as TEXEDIT or LESSEDIT. export PSQLEDIT='mate -w -l %d "%s"' or export PSQLEDIT='emacs +%d "%s"' Cheers, Steve
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 function source code without any decorations - good for copy/paste \sf+ funcname ... show function and add line numbers, maybe others in future \sf+ funcname, line ... show function from line \sf ... show function - name and line take from error message + add new system variable PG_EDITOR_OPTION ?? what do you think about? Regards Pavel 2010/3/22 Peter Eisentraut <peter_e@gmx.net>: > 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 filename". > > I think that's a pretty widely spread convention. A quick test shows > that all of emacs, vi, joe, and nano support this. Of course there are > editors that don't support it, so we'll have to distinguish that > somehow, but it won't be too complicated to support a few of the common > editors. > > >