Horton
Menu

Thread

  1. proposal: more practical view on function's source code

    Pavel Stehule <pavel.stehule@gmail.com> — 2010-03-21T12:03:18Z

    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

  2. Re: proposal: more practical view on function's source code

    Craig Ringer <craig@postnewspapers.com.au> — 2010-03-21T14:02:22Z

    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

  3. Re: proposal: more practical view on function's source code

    Pavel Stehule <pavel.stehule@gmail.com> — 2010-03-21T14:33:55Z

    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
>

  4. Re: proposal: more practical view on function's source code

    Craig Ringer <craig@postnewspapers.com.au> — 2010-03-21T14:39:35Z

    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

  5. Re: proposal: more practical view on function's source code

    Pavel Stehule <pavel.stehule@gmail.com> — 2010-03-21T14:52:08Z

    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
>

  6. Re: proposal: more practical view on function's source code

    Tom Lane <tgl@sss.pgh.pa.us> — 2010-03-21T15:42:46Z

    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

  7. Re: proposal: more practical view on function's source code

    Pavel Stehule <pavel.stehule@gmail.com> — 2010-03-21T16:09:40Z

    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
>

  8. Re: proposal: more practical view on function's source code

    Dimitri Fontaine <dfontaine@hi-media.com> — 2010-03-21T17:51:52Z

    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

  9. Re: proposal: more practical view on function's source code

    Andrew Dunstan <andrew@dunslane.net> — 2010-03-21T18:00:31Z

    
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

  10. Re: proposal: more practical view on function's source code

    Tom Lane <tgl@sss.pgh.pa.us> — 2010-03-21T18:08:57Z

    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

  11. Re: proposal: more practical view on function's source code

    Dimitri Fontaine <dfontaine@hi-media.com> — 2010-03-21T19:01:37Z

    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

  12. Re: proposal: more practical view on function's source code

    Pavel Stehule <pavel.stehule@gmail.com> — 2010-03-21T19:06:19Z

    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 is null 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 │ begin
 2 │   for i in 1..3 loop
 3 │     raise notice 'i=%', i/0;
 4 │   end loop;
 5 │ end;
 6 │ $function$
   │
(11 rows)

regards
Pavel Stehule

>
>                        regards, tom lane
>

  13. Re: proposal: more practical view on function's source code

    Robert Haas <robertmhaas@gmail.com> — 2010-03-21T20:27:39Z

    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

  14. Re: proposal: more practical view on function's source code

    Tom Lane <tgl@sss.pgh.pa.us> — 2010-03-21T20:35:48Z

    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

  15. Re: proposal: more practical view on function's source code

    Robert Haas <robertmhaas@gmail.com> — 2010-03-22T00:40:38Z

    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

  16. Re: proposal: more practical view on function's source code

    Pavel Stehule <pavel.stehule@gmail.com> — 2010-03-22T03:53:45Z

    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
>

  17. Re: proposal: more practical view on function's source code

    Pavel Stehule <pavel.stehule@gmail.com> — 2010-03-22T04:10:56Z

    >
> 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
>

  18. Re: proposal: more practical view on function's source code

    Dimitri Fontaine <dfontaine@hi-media.com> — 2010-03-22T12:49:46Z

    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

  19. Re: proposal: more practical view on function's source code

    Pavel Stehule <pavel.stehule@gmail.com> — 2010-03-22T14:35:03Z

    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
>
>

  20. Re: proposal: more practical view on function's source code

    Peter Eisentraut <peter_e@gmx.net> — 2010-03-22T21:23:43Z

    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.

  21. Re: proposal: more practical view on function's source code

    Steve Atkins <steve@blighty.com> — 2010-03-22T21:54:36Z

    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

  22. Re: proposal: more practical view on function's source code

    Pavel Stehule <pavel.stehule@gmail.com> — 2010-03-23T07:58:20Z

    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.
>
>
>