Pavel Stehule writes:
> attached updated \sf implementation. It is little bit simplyfied with
> support a pager and output forwarding. Formating was updated per Tom's
> request.
Applied with corrections --- mostly, fixing it to not trash the query
buffer, which would certainly not be expected beh
Pavel Stehule writes:
> attached updated \sf implementation. It is little bit simplyfied with
> support a pager and output forwarding.
The line number argument to this greatly complicates the code but
doesn't appear to me to have much practical use. Why would you bother
with that?
Hello
attached updated \sf implementation. It is little bit simplyfied with
support a pager and output forwarding. Formating was updated per Tom's
request.
Regards
Pavel Stehule
>
> BTW, the last I looked, \sf+ was using what I thought to be a quite ugly
> and poorly-considered formatting for t
2010/8/11 Robert Haas :
> On Wed, Aug 11, 2010 at 12:28 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Tue, Aug 10, 2010 at 11:58 PM, Tom Lane wrote:
BTW, at least in the usage in that loop, get_functiondef_dollarquote_tag
seems grossly overdesigned. It would be clearer, shorter, a
Robert Haas writes:
> I suggest that we punt the \sf portion of this patch back for rework for
> the next CommitFest, and focus on getting the \e and \ef changes
> committed. I think the \sf code can be a lot simpler if we get rid of
> the code that's intended to recognize the ending delimeter.
On Wed, Aug 11, 2010 at 6:21 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... If you're still unhappy with it, you're going to need to
>> be more specific, or hack on it yourself.
>
> I'm doing another pass over this. I notice that the documentation
> claims the syntax of \e is "\e [FILE] [LINE
Robert Haas writes:
> ... If you're still unhappy with it, you're going to need to
> be more specific, or hack on it yourself.
I'm doing another pass over this. I notice that the documentation
claims the syntax of \e is "\e [FILE] [LINE]", but what is actually
implemented is "\e [FILE [LINE]]",
On Wed, Aug 11, 2010 at 12:28 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Aug 10, 2010 at 11:58 PM, Tom Lane wrote:
>>> BTW, at least in the usage in that loop, get_functiondef_dollarquote_tag
>>> seems grossly overdesigned. It would be clearer, shorter, and faster if
>>> you just had
Robert Haas writes:
> On Tue, Aug 10, 2010 at 11:58 PM, Tom Lane wrote:
>> BTW, at least in the usage in that loop, get_functiondef_dollarquote_tag
>> seems grossly overdesigned. It would be clearer, shorter, and faster if
>> you just had a strncmp test for "AS $function" there.
> As far as I c
On Tue, Aug 10, 2010 at 11:58 PM, Tom Lane wrote:
> The \e patch definitely needs another read-through. I noticed a number
> of comments that were still pretty poor English, and one ---
> /* skip header lines */
> --- that seems just plain wrong. The actual intent of that next bit is
> to
Robert Haas writes:
> I spent some time cleaning this up tonight. I think that the \e and
> \ef portions are now ready to commit, but I am not quite happy with
> the \sf stuff yet, so I've broken that out into a separate patch,
> which is also attached.
> Barring objections, I'll commit the \e a
On Mon, Aug 9, 2010 at 7:40 AM, Pavel Stehule wrote:
> updated patch attached
I spent some time cleaning this up tonight. I think that the \e and
\ef portions are now ready to commit, but I am not quite happy with
the \sf stuff yet, so I've broken that out into a separate patch,
which is also at
2010/8/9 David E. Wheeler :
> On Aug 8, 2010, at 8:38 PM, Tom Lane wrote:
>
>> Um, but \sf *doesn't* give you anything that's usefully copy and
>> pasteable. And if that were the goal, why doesn't it have an option to
>> write to a file?
>>
>> But it's really the line numbers shoved in front that
On Aug 8, 2010, at 8:38 PM, Tom Lane wrote:
> Um, but \sf *doesn't* give you anything that's usefully copy and
> pasteable. And if that were the goal, why doesn't it have an option to
> write to a file?
>
> But it's really the line numbers shoved in front that I'm on about here.
> I can't see *a
2010/8/9 Robert Haas :
> On Sun, Aug 8, 2010 at 11:38 PM, Tom Lane wrote:
>> Um, but \sf *doesn't* give you anything that's usefully copy and
>> pasteable.
>
> Works for me.
>
> \sf ts_debug(regconfig, text)
>
>> And if that were the goal, why doesn't it have an option to
>> write to a file?
>
> W
On Sun, Aug 8, 2010 at 11:38 PM, Tom Lane wrote:
> Um, but \sf *doesn't* give you anything that's usefully copy and
> pasteable.
Works for me.
\sf ts_debug(regconfig, text)
> And if that were the goal, why doesn't it have an option to
> write to a file?
Well, you cut-and-paste from a terminal
Hello
2010/8/8 Tom Lane :
> Pavel Stehule writes:
>> updated patch attached
>
> What exactly is the point of the \sf command? It seems like quite a lot
> of added code for a feature that nobody has requested, and whose
> definition is about as ad-hoc as could be. Personally I'd much sooner
> us
2010/8/9 Tom Lane :
> Robert Haas writes:
>> On Sun, Aug 8, 2010 at 1:14 PM, Tom Lane wrote:
>>> What exactly is the point of the \sf command?
>
>> I rather like \sf, actually; in fact, I think there's a decent
>> argument to be made that it's more useful than the line-numbering
>> stuff for \ef.
Robert Haas writes:
> On Sun, Aug 8, 2010 at 1:14 PM, Tom Lane wrote:
>> What exactly is the point of the \sf command?
> I rather like \sf, actually; in fact, I think there's a decent
> argument to be made that it's more useful than the line-numbering
> stuff for \ef. I don't particularly like
On Sun, Aug 8, 2010 at 1:14 PM, Tom Lane wrote:
> Pavel Stehule writes:
>> updated patch attached
>
> What exactly is the point of the \sf command? It seems like quite a lot
> of added code for a feature that nobody has requested, and whose
> definition is about as ad-hoc as could be. Personall
2010/8/8 Tom Lane :
> Pavel Stehule writes:
>> updated patch attached
>
> What exactly is the point of the \sf command? It seems like quite a lot
> of added code for a feature that nobody has requested, and whose
> definition is about as ad-hoc as could be. Personally I'd much sooner
> use \ef f
Pavel Stehule writes:
> updated patch attached
What exactly is the point of the \sf command? It seems like quite a lot
of added code for a feature that nobody has requested, and whose
definition is about as ad-hoc as could be. Personally I'd much sooner
use \ef for looking at a function definit
Robert Haas writes:
> On Wed, Aug 4, 2010 at 8:50 PM, Greg Stark wrote:
>> On Wed, Aug 4, 2010 at 3:35 PM, Tom Lane wrote:
>>> Well, the thing about $EDITOR is that it's a very-widely-understood
>>> convention. This one won't be, so the argument for making it an
>>> environment variable seems p
On Wed, Aug 4, 2010 at 8:50 PM, Greg Stark wrote:
> On Wed, Aug 4, 2010 at 3:35 PM, Tom Lane wrote:
>> Well, the thing about $EDITOR is that it's a very-widely-understood
>> convention. This one won't be, so the argument for making it an
>> environment variable seems pretty thin.
>
> Fwiw the +l
On Wed, Aug 4, 2010 at 3:35 PM, Tom Lane wrote:
> Well, the thing about $EDITOR is that it's a very-widely-understood
> convention. This one won't be, so the argument for making it an
> environment variable seems pretty thin.
Fwiw the +linenumber convention has been part of $EDITOR since
basical
David Fetter writes:
> On Mon, Aug 02, 2010 at 11:34:02PM -0400, Robert Haas wrote:
>> A side question is whether this should be an environment variable or
>> a psql variable.
> I'd say "yes." As with $EDITOR/PSQL_EDITOR, there should be something
> that looks for an overriding psql variable, dr
Hello
updated patch attached
2010/8/4 Robert Haas :
> On Tue, Aug 3, 2010 at 7:20 AM, Pavel Stehule wrote:
>> I hope so I found and fixed last issue - the longer functions was
>> showed directly - without a pager.
>
> As a matter of style, I suggest leaving bool *edited as the last
> argument to
On Wed, Aug 4, 2010 at 10:10 AM, David Fetter wrote:
> On Mon, Aug 02, 2010 at 11:34:02PM -0400, Robert Haas wrote:
>> On Mon, Aug 2, 2010 at 11:17 PM, Tom Lane wrote:
>> > Robert Haas writes:
>> >> On Mon, Aug 2, 2010 at 10:49 PM, Tom Lane wrote:
>>
>> Well, it'd still work fine for \e foo. I
On Mon, Aug 02, 2010 at 11:34:02PM -0400, Robert Haas wrote:
> On Mon, Aug 2, 2010 at 11:17 PM, Tom Lane wrote:
> > Robert Haas writes:
> >> On Mon, Aug 2, 2010 at 10:49 PM, Tom Lane wrote:
>
> Well, it'd still work fine for \e foo. It'll just blow up for \e
> foo 3. My concern isn't really t
On Tue, Aug 3, 2010 at 7:20 AM, Pavel Stehule wrote:
> I hope so I found and fixed last issue - the longer functions was
> showed directly - without a pager.
As a matter of style, I suggest leaving bool *edited as the last
argument to do_edit() and inserting int lineno as the second-to-last
argum
Hello
I hope so I found and fixed last issue - the longer functions was
showed directly - without a pager.
Regards
Pavel
2010/8/3 Pavel Stehule :
> Hello
>
> 2010/8/3 Pavel Stehule :
>> attached updated patch
>>
>> * don't use a default option for navigation in editor - user have to
>> set this
Hello
2010/8/3 Pavel Stehule :
> attached updated patch
>
> * don't use a default option for navigation in editor - user have to
> set this option explicitly
> * name for this psql variable is EDITOR_LINENUMBER_SWITCH -
> * updated comments, doc and some issues described by Robert
>
> Regards
>
>
attached updated patch
* don't use a default option for navigation in editor - user have to
set this option explicitly
* name for this psql variable is EDITOR_LINENUMBER_SWITCH -
* updated comments, doc and some issues described by Robert
Regards
Pavel Stehule
2010/8/3 Robert Haas :
> On Sun, A
2010/8/3 Robert Haas :
> On Mon, Aug 2, 2010 at 11:17 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Mon, Aug 2, 2010 at 10:49 PM, Tom Lane wrote:
I'm tempted
to suggest forgetting about any user-configurable parameter and just
provide code that strcmp's the $EDITOR value to se
2010/8/3 Robert Haas :
> On Sun, Aug 1, 2010 at 11:48 PM, Robert Haas wrote:
>>> b) more robust algorithm for header rows identification
>>
>> Have not gotten to this one yet.
>
> I notIce that on WIN32 the default editor is notepad.exe and the
> default editor navigation option is "/". Does "not
On Mon, Aug 2, 2010 at 11:17 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Aug 2, 2010 at 10:49 PM, Tom Lane wrote:
>>> I'm tempted
>>> to suggest forgetting about any user-configurable parameter and just
>>> provide code that strcmp's the $EDITOR value to see if it recognizes the
>>> edi
Robert Haas writes:
> On Mon, Aug 2, 2010 at 10:49 PM, Tom Lane wrote:
>> I'm tempted
>> to suggest forgetting about any user-configurable parameter and just
>> provide code that strcmp's the $EDITOR value to see if it recognizes the
>> editor name, otherwise do nothing.
> With all due respect,
On Mon, Aug 2, 2010 at 10:49 PM, Tom Lane wrote:
> Robert Haas writes:
>> This is actually my biggest concern about this patch - that it may be
>> just too much of a hassle to actually make it work for people. I just
>> tried setting $EDITOR to MacOS's TextEdit program, and it turns out
>> that
Robert Haas writes:
> This is actually my biggest concern about this patch - that it may be
> just too much of a hassle to actually make it work for people. I just
> tried setting $EDITOR to MacOS's TextEdit program, and it turns out
> that TextEdit doesn't understand +. I'm afraid that we're go
On Sun, Aug 1, 2010 at 11:48 PM, Robert Haas wrote:
>> b) more robust algorithm for header rows identification
>
> Have not gotten to this one yet.
I notIce that on WIN32 the default editor is notepad.exe and the
default editor navigation option is "/". Does "notepad.exe /lineno
filename" actual
On Sun, Aug 1, 2010 at 4:53 PM, Pavel Stehule wrote:
> a) remove special row number handling of plpgsql (first patch)
Committed.
> b) more robust algorithm for header rows identification
Have not gotten to this one yet.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise P
Hello
I am sending a modified patch - changes:
a) remove special row number handling of plpgsql (first patch)
b) more robust algorithm for header rows identification
Regards
Pavel Stehule
2010/8/1 Robert Haas :
> On Sun, Aug 1, 2010 at 10:47 AM, Tom Lane wrote:
>> Pavel Stehule writes:
>>> s
Robert Haas writes:
> On Sun, Aug 1, 2010 at 11:35 AM, Tom Lane wrote:
>> Personally, rather than sweat about what the exact definition of line
>> numbers is, I think we should be moving further in the direction of
>> being able to regurgitate source text to identify error locations.
> I basical
On Sun, Aug 1, 2010 at 11:35 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Aug 1, 2010 at 10:47 AM, Tom Lane wrote:
>>> The need to count lines manually in function definitions is
>>> far less than it was back when that kluge was put in.
>
>> Why?
>
> That hack goes back to plpgsql's preh
Robert Haas writes:
> On Sun, Aug 1, 2010 at 10:47 AM, Tom Lane wrote:
>> The need to count lines manually in function definitions is
>> far less than it was back when that kluge was put in.
> Why?
That hack goes back to plpgsql's prehistory (it's there, though sans
comment, in plpgsql's scan.l
2010/8/1 Robert Haas :
> On Sun, Aug 1, 2010 at 10:47 AM, Tom Lane wrote:
>> Pavel Stehule writes:
>>> so my plan
>>
>>> a) fix problem with ambiguous $function* like you proposed
>>> b) fix problem with "first row excepting" - I can activate a detection
>>> only for plpgsql language - I can iden
On Sun, Aug 1, 2010 at 10:47 AM, Tom Lane wrote:
> Pavel Stehule writes:
>> so my plan
>
>> a) fix problem with ambiguous $function* like you proposed
>> b) fix problem with "first row excepting" - I can activate a detection
>> only for plpgsql language - I can identify LANGUAGE before.
>
> Ick.
Pavel Stehule writes:
> so my plan
> a) fix problem with ambiguous $function* like you proposed
> b) fix problem with "first row excepting" - I can activate a detection
> only for plpgsql language - I can identify LANGUAGE before.
Ick. We should absolutely NOT have a client-side special case fo
2010/8/1 Robert Haas :
> On Sun, Aug 1, 2010 at 12:15 AM, Pavel Stehule
> wrote:
>> 2010/8/1 Robert Haas :
>>> On Sun, Jul 25, 2010 at 11:42 AM, Pavel Stehule
>>> wrote:
> I'm setting this as ready for committer.
Thank you very much
>>>
>>> I took a look at this tonight and am a b
On Sun, Aug 1, 2010 at 12:15 AM, Pavel Stehule wrote:
> 2010/8/1 Robert Haas :
>> On Sun, Jul 25, 2010 at 11:42 AM, Pavel Stehule
>> wrote:
I'm setting this as ready for committer.
>>>
>>> Thank you very much
>>
>> I took a look at this tonight and am a bit mystified by the following bit:
>
2010/8/1 Robert Haas :
> On Sun, Jul 25, 2010 at 11:42 AM, Pavel Stehule
> wrote:
>>> I'm setting this as ready for committer.
>>
>> Thank you very much
>
> I took a look at this tonight and am a bit mystified by the following bit:
>
> + /*
> + * PL do
Robert Haas writes:
> I took a look at this tonight and am a bit mystified by the following bit:
> + /*
> +* PL doesn't calculate first row of function's body
> +* when first row is empty. So checks first row, and
> +
On Sun, Jul 25, 2010 at 11:42 AM, Pavel Stehule wrote:
>> I'm setting this as ready for committer.
>
> Thank you very much
I took a look at this tonight and am a bit mystified by the following bit:
+ /*
+* PL doesn't calculate first row of function's
2010/7/25 Jan Urbański :
> On 23/07/10 20:55, Pavel Stehule wrote:
>> Hello
>>
>> 2010/7/23 Jan Urbański :
>>> On 21/07/10 14:43, Pavel Stehule wrote:
Hello
I am sending a actualised patch.
>
> OK, thanks. This time the only thing I'm not happy about is the error
> message from doing
On 23/07/10 20:55, Pavel Stehule wrote:
> Hello
>
> 2010/7/23 Jan Urbański :
>> On 21/07/10 14:43, Pavel Stehule wrote:
>>> Hello
>>>
>>> I am sending a actualised patch.
OK, thanks. This time the only thing I'm not happy about is the error
message from doing:
\ef func 0
\e /etc/passwd xxx
whic
Hello
2010/7/23 Jan Urbański :
> On 21/07/10 14:43, Pavel Stehule wrote:
>> Hello
>>
>> I am sending a actualised patch.
>
> Hi, thanks!
>
>> I understand to your criticism about line numbering. I have to
>> agree. With line numbering the patch is longer. I have a one
>> significant reason for it.
On Thu, Jul 22, 2010 at 6:56 PM, Jan Urbański wrote:
> the rest are just stylistic nitpicks.
But, if the patch author doesn't fix them, the committer has to, so
your nitpicking is much appreciated, at least by me!
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres
On 21/07/10 14:43, Pavel Stehule wrote:
> Hello
>
> I am sending a actualised patch.
Hi, thanks!
> I understand to your criticism about line numbering. I have to
> agree. With line numbering the patch is longer. I have a one
> significant reason for it.
> CREATE OR REPLACE FUNCTION public
On Fri, Jul 16, 2010 at 10:29 AM, Jan Urbański wrote:
> The patch adds the following features:
> * \e file.txt num -> starts a editor for the current query buffer and
> puts the cursor on the [num] line
> * \ef func num -> starts a editor for a function and puts the cursor on the
> [num] line
Pavel Stehule writes:
> CREATE OR REPLACE FUNCTION public.foo()
> RETURNS integer
> LANGUAGE plpgsql
>1 AS $function$ begin
>2 return 10/0;
>3 end;
> $function$
>
> This is very trivial example - for more complex functions, the correct
> line numbering is m
Hello
I am sending a actualised patch.
I understand to your criticism about line numbering. I have to agree.
With line numbering the patch is longer. I have a one significant
reason for it. There are not conformance between line numbers of
CREATE FUNCTION statement and line numbers of function's
Hello
2010/7/16 Jan Urbański :
> Hi,
>
> here's a review of the \sf and \ef [num] patch from
> http://archives.postgresql.org/message-id/162867791003290927y3ca44051p80e697bc6b19d...@mail.gmail.com
>
> == Formatting ==
>
> The patch has some small tabs/spaces and whitespace issues and it applies
>
62 matches
Mail list logo
