Hi
2016-10-08 23:46 GMT+02:00 Jim Nasby :
> On 10/3/16 3:18 PM, Pavel Stehule wrote:
>
>> I am feeling consensus on removing source of PL from \dt+. There is
>> partial consensus on saving this field (renamed) for C and internal
>> language. I am not sure about consensus about \sf enhancing.
>>
>
On 10/3/16 3:18 PM, Pavel Stehule wrote:
I am feeling consensus on removing source of PL from \dt+. There is
partial consensus on saving this field (renamed) for C and internal
language. I am not sure about consensus about \sf enhancing.
FWIW, I'm completely in favor of ditching PL source code.
2016-10-03 22:03 GMT+02:00 Tom Lane :
> Pavel Stehule writes:
> > 2016-10-03 21:54 GMT+02:00 Robert Haas :
> >> On Fri, Sep 30, 2016 at 8:47 PM, Tom Lane wrote:
> >>> Personally I'm on the edge of washing my hands of the whole thing...
>
> >> The hand-washing strategy has a lot to recommend it;
Pavel Stehule writes:
> 2016-10-03 21:54 GMT+02:00 Robert Haas :
>> On Fri, Sep 30, 2016 at 8:47 PM, Tom Lane wrote:
>>> Personally I'm on the edge of washing my hands of the whole thing...
>> The hand-washing strategy has a lot to recommend it; this thread is
>> going nowhere fast. I don't car
2016-10-03 21:54 GMT+02:00 Robert Haas :
> On Fri, Sep 30, 2016 at 8:47 PM, Tom Lane wrote:
> > Well, alternatively, can we get a consensus for doing that? People
> > did speak against removing PL source code from \df+ altogether, but
> > maybe they're willing to reconsider if the alternative is
On Fri, Sep 30, 2016 at 8:47 PM, Tom Lane wrote:
> Well, alternatively, can we get a consensus for doing that? People
> did speak against removing PL source code from \df+ altogether, but
> maybe they're willing to reconsider if the alternative is doing nothing.
>
> Personally I'm on the edge of
On Sun, Oct 2, 2016 at 10:55 PM, Michael Paquier
wrote:
> Let's remove it and move on then. By looking again at this thread and
> particularly
> https://www.postgresql.org/message-id/20160926190618.gh5...@tamriel.snowman.net
> (thanks Stephen for the summary) that's where we are heading to.
(Mov
On Sat, Oct 1, 2016 at 9:47 AM, Tom Lane wrote:
> Jim Nasby writes:
>> On 9/28/16 2:59 PM, Alvaro Herrera wrote:
>>> My vote (which was not counted by Stephen) was to remove it from \df+
>>> altogether. I stand by that. People who are used to seeing the output
>>> in \df+ will wonder "where the
Jim Nasby writes:
> On 9/28/16 2:59 PM, Alvaro Herrera wrote:
>> My vote (which was not counted by Stephen) was to remove it from \df+
>> altogether. I stand by that. People who are used to seeing the output
>> in \df+ will wonder "where the heck did it go" and eventually figure it
>> out, at wh
On 9/28/16 2:59 PM, Alvaro Herrera wrote:
I am sorry, I disagree. Proposed form is hard readable. Is not possible to
> simply copy/paste.
Why do you care? You can use \sf if you want to copy&paste the
function code.
> I cannot to imagine any use case for proposed format.
My vote (which was n
On Thu, Sep 29, 2016 at 12:07 AM, Pavel Stehule
wrote:
> Hi
>
> 2016-09-28 18:57 GMT+02:00 Tom Lane :
>
>> Pavel Stehule writes:
>> > 2016-09-28 16:03 GMT+02:00 Tom Lane :
>> >> I propose to push my current patch (ie, move PL function
>> >> source code to \df+ footers), and we can use it in HEAD
Pavel Stehule writes:
> We are in cycle because prosrc field is used for two independent features -
> and then it can be hard to find a agreement.
I thought pretty much everyone was on board with the idea of keeping
prosrc in \df+ for internal/C-language functions (and then probably
renaming the
2016-09-28 21:59 GMT+02:00 Alvaro Herrera :
> Pavel Stehule wrote:
>
> > I am sorry, I disagree. Proposed form is hard readable. Is not possible
> to
> > simply copy/paste.
>
> Why do you care? You can use \sf if you want to copy&paste the
> function code.
>
I know so I can use \sf. But I don't
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Pavel Stehule wrote:
> > I cannot to imagine any use case for proposed format.
>
> My vote (which was not counted by Stephen) was to remove it from \df+
Oh, sorry about that, not sure how I missed it. :/
> altogether. I stand by that. People
Pavel Stehule wrote:
> I am sorry, I disagree. Proposed form is hard readable. Is not possible to
> simply copy/paste.
Why do you care? You can use \sf if you want to copy&paste the
function code.
> I cannot to imagine any use case for proposed format.
My vote (which was not counted by Stephen
Hi
2016-09-28 18:57 GMT+02:00 Tom Lane :
> Pavel Stehule writes:
> > 2016-09-28 16:03 GMT+02:00 Tom Lane :
> >> I propose to push my current patch (ie, move PL function
> >> source code to \df+ footers), and we can use it in HEAD for awhile
> >> and see what we think. We can alway improve or re
Pavel Stehule writes:
> 2016-09-28 16:03 GMT+02:00 Tom Lane :
>> I propose to push my current patch (ie, move PL function
>> source code to \df+ footers), and we can use it in HEAD for awhile
>> and see what we think. We can alway improve or revert it later.
> I had some objection to format of s
2016-09-28 16:03 GMT+02:00 Tom Lane :
> Rushabh Lathia writes:
> > On Mon, Sep 26, 2016 at 3:06 PM, Stephen Frost
> wrote:
> >> I feel like we're getting wrapped around the axle as it regards who is
> >> perceived to be voting for what.
>
> > Thanks Stephen Frost for listing down all the concern
Rushabh Lathia writes:
> On Mon, Sep 26, 2016 at 3:06 PM, Stephen Frost wrote:
>> I feel like we're getting wrapped around the axle as it regards who is
>> perceived to be voting for what.
> Thanks Stephen Frost for listing down all the concerns from the people
> on the different approaches.
I'
On Mon, Sep 26, 2016 at 3:06 PM, Stephen Frost wrote:
> I feel like we're getting wrapped around the axle as it regards who is
> perceived to be voting for what.
Thanks Stephen Frost for listing down all the concerns from the people
on the different approaches.
On Tue, Sep 27, 2016 at 7:56 PM, S
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> I think the debate is more about whether moving the source display
> functionality over to \sf is a better solution than rearranging \df+
> output. (If we had consensus to do that, I'd be happy to go code it,
> but I'm not going to invest the effort when it
Robert Haas writes:
> On Mon, Sep 26, 2016 at 3:06 PM, Stephen Frost wrote:
>> That doesn't mean, at least to me, that we should forgo considering
>> better alternatives.
> I don't think so, either, but if we could agree that "Tom's patch >
> doing nothing" then he could commit it and we could d
On Mon, Sep 26, 2016 at 3:06 PM, Stephen Frost wrote:
> I feel like we're getting wrapped around the axle as it regards who is
> perceived to be voting for what.
True. It's not very clear; thanks for trying to shed some light on it.
> I don't particularly care for it either, primairly because \
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Sep 26, 2016 at 10:48 AM, Stephen Frost wrote:
> > I agree that "do nothing" isn't a good option. I'm not terribly
> > thrilled with just putting the source code at the bottom of the \df+
> > output either, though it's at least slightly less
On Mon, Sep 26, 2016 at 10:48 AM, Stephen Frost wrote:
> I agree that "do nothing" isn't a good option. I'm not terribly
> thrilled with just putting the source code at the bottom of the \df+
> output either, though it's at least slightly less ridiculous than trying
> to put the source code into
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Pavel Stehule writes:
> > 2016-09-23 7:22 GMT+02:00 Rushabh Lathia :
> >> On Thu, Sep 22, 2016 at 10:04 PM, Tom Lane wrote:
> >>> If it's unreadable in \df+, how would \df++ make that any better?
>
> >> Eventhough source code as part of \df+ is bit annoyi
Pavel Stehule writes:
> 2016-09-23 7:22 GMT+02:00 Rushabh Lathia :
>> On Thu, Sep 22, 2016 at 10:04 PM, Tom Lane wrote:
>>> If it's unreadable in \df+, how would \df++ make that any better?
>> Eventhough source code as part of \df+ is bit annoying (specifically
>> for PL functions), I noticed th
2016-09-23 7:22 GMT+02:00 Rushabh Lathia :
>
>
> On Thu, Sep 22, 2016 at 10:04 PM, Tom Lane wrote:
>
>> Rushabh Lathia writes:
>> > I agree with the argument in this thread, having "Source code" as part
>> > of \df+ is bit annoying, specifically when output involve some really
>> > big PL langua
On Thu, Sep 22, 2016 at 10:04 PM, Tom Lane wrote:
> Rushabh Lathia writes:
> > I agree with the argument in this thread, having "Source code" as part
> > of \df+ is bit annoying, specifically when output involve some really
> > big PL language functions. Having is separate does make \df+ output
Rushabh Lathia writes:
> I agree with the argument in this thread, having "Source code" as part
> of \df+ is bit annoying, specifically when output involve some really
> big PL language functions. Having is separate does make \df+ output more
> readable. So I would vote for \df++ rather then addin
I agree with the argument in this thread, having "Source code" as part of
\df+
is bit annoying, specifically when output involve some really big PL
language
functions. Having is separate does make \df+ output more readable. So I
would
vote for \df++ rather then adding the source code as part of foo
Hi
2016-09-06 0:05 GMT+02:00 Tom Lane :
> I wrote:
> > Pavel Stehule writes:
> >> Using footer for this purpose is little bit strange. What about
> following
> >> design?
> >> 1. move out source code of PL functions from \df+
> >> 2. allow not unique filter in \sf and allow to display multiple
>
I wrote:
> Pavel Stehule writes:
>> Using footer for this purpose is little bit strange. What about following
>> design?
>> 1. move out source code of PL functions from \df+
>> 2. allow not unique filter in \sf and allow to display multiple functions
> Wasn't that proposed and rejected upthread?
Pavel Stehule writes:
> Using footer for this purpose is little bit strange. What about following
> design?
> 1. move out source code of PL functions from \df+
> 2. allow not unique filter in \sf and allow to display multiple functions
Wasn't that proposed and rejected upthread?
2016-08-24 15:42 GMT+02:00 Tom Lane :
> Peter Eisentraut writes:
> > On 8/22/16 1:52 PM, Pavel Stehule wrote:
> >> If I understand to purpose of this patch - it is compromise - PL source
> >> is removed from table, but it is printed in result.
>
> > What does it do if you are displaying more than
I wrote:
> Peter Eisentraut writes:
>> What does it do if you are displaying more than one function?
> It prints more than one footer. It's very much like the way that, say,
> rules are printed for tables by \d.
Or to be concrete: instead of
regression=# \df+ foo*
Peter Eisentraut writes:
> On 8/22/16 1:52 PM, Pavel Stehule wrote:
>> If I understand to purpose of this patch - it is compromise - PL source
>> is removed from table, but it is printed in result.
> What does it do if you are displaying more than one function?
It prints more than one footer. I
On 8/22/16 1:52 PM, Pavel Stehule wrote:
> If I understand to purpose of this patch - it is compromise - PL source
> is removed from table, but it is printed in result.
What does it do if you are displaying more than one function?
--
Peter Eisentraut http://www.2ndQuadrant.com/
Post
2016-08-22 18:19 GMT+02:00 Robert Haas :
> On Mon, Aug 22, 2016 at 4:49 AM, Pavel Stehule
> wrote:
> > This feature shows source code for PL function when \df statement was
> used.
> > I am not too sure, if this functionality is necessary - but I don't see
> any
> > argument against. Sometimes it
On Mon, Aug 22, 2016 at 4:49 AM, Pavel Stehule wrote:
> This feature shows source code for PL function when \df statement was used.
> I am not too sure, if this functionality is necessary - but I don't see any
> argument against. Sometimes it can be useful, mainly when we work with
> overloaded fu
Hi
2016-07-13 19:01 GMT+02:00 Tom Lane :
> Peter Eisentraut writes:
> > On 7/12/16 7:11 PM, Stephen Frost wrote:
> >> I'm curious how it's useful and in what way \sf does not accomplish what
> >> you use \df+ for.
>
> > One main use is to see multiple related functions next to each other and
>
On Jul 13, 2016, at 12:25 PM, Stephen Frost wrote:
> I disagree. Adding a column is certainly changing the structure, as is
> removing one. This certainly hasn't changed my opinion that it's
> worthwhile to consider this change, even at this point in the release
> cycle, given we need to make a
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 7/12/16 7:11 PM, Stephen Frost wrote:
> > I'm curious how it's useful and in what way \sf does not accomplish what
> > you use \df+ for.
>
> One main use is to see multiple related functions next to each other and
> compare their so
Peter Eisentraut writes:
> On 7/12/16 7:11 PM, Stephen Frost wrote:
>> I'm curious how it's useful and in what way \sf does not accomplish what
>> you use \df+ for.
> One main use is to see multiple related functions next to each other and
> compare their source code. But also because one is use
On 7/12/16 7:11 PM, Stephen Frost wrote:
> I'm curious how it's useful and in what way \sf does not accomplish what
> you use \df+ for.
One main use is to see multiple related functions next to each other and
compare their source code. But also because one is used to \df and
wants to see everythi
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 7/12/16 12:17 PM, Tom Lane wrote:
> > It's sounding to me like we have consensus on this proposal to further
> > change \df+ to replace the "Source code" column with "Internal name",
> > which is prosrc for C and internal-language fu
Peter Eisentraut wrote:
> I'm quite fond of having the full source code show in \df+ and I'm
> against removing it on short notice past beta2, discussed under a
> "false" subject heading.
How do you use it?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x
On 7/12/16 12:17 PM, Tom Lane wrote:
> It's sounding to me like we have consensus on this proposal to further
> change \df+ to replace the "Source code" column with "Internal name",
> which is prosrc for C and internal-language functions but NULL otherwise.
>
> If I've not heard objections by tomo
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Are we satisfied with telling people to use \sf to see the source code
> >> for a PL function? Or should there be another variant of \df that
> >> still provides source code?
>
> > I do
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Are we satisfied with telling people to use \sf to see the source code
>> for a PL function? Or should there be another variant of \df that
>> still provides source code?
> I don't see the point in having a \df variant be the same
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Agreed. I don't have any issue with "Language", really, but I agree
> > that "Source code" makes the output pretty ridiculous. I also liked the
> > idea of changing the name to "internal name" or something along those
> > lines,
Stephen Frost writes:
> Agreed. I don't have any issue with "Language", really, but I agree
> that "Source code" makes the output pretty ridiculous. I also liked the
> idea of changing the name to "internal name" or something along those
> lines, rather than having it be "source code", if we kee
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Michael Paquier writes:
> > On Tue, Jul 12, 2016 at 11:36 AM, Alvaro Herrera
> > wrote:
> >> So prosrc for internal/C and NULL for others? WFM.
>
> > And so we'd remove "Language" at the same time? That does not sound bad to
> > me.
>
> Hm, I wasn't th
Michael Paquier writes:
> On Tue, Jul 12, 2016 at 11:36 AM, Alvaro Herrera
> wrote:
>> So prosrc for internal/C and NULL for others? WFM.
> And so we'd remove "Language" at the same time? That does not sound bad to me.
Hm, I wasn't thinking of that step. The main knock on "Source code" is
tha
On Tue, Jul 12, 2016 at 11:36 AM, Alvaro Herrera
wrote:
> Stephen Frost wrote:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>
>> > It would certainly be easy enough to do that, as long as you don't mind
>> > hard-wiring into psql the knowledge that "internal" and "C" are the
>> > languages to show pr
Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > It would certainly be easy enough to do that, as long as you don't mind
> > hard-wiring into psql the knowledge that "internal" and "C" are the
> > languages to show prosrc for. "Source code" would no longer be a very
> > appropria
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I agree with removing the source code field, though I did like the
> > suggestion mentioned elsewhere for having it shown when it's just a C
> > symbol but not otherwise. If we can find a way to have the C symbol
> > shown when it
Stephen Frost writes:
> I agree with removing the source code field, though I did like the
> suggestion mentioned elsewhere for having it shown when it's just a C
> symbol but not otherwise. If we can find a way to have the C symbol
> shown when it's a C or internal function, I'm fine with that,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Michael Paquier writes:
> > On Mon, Jul 11, 2016 at 12:42 AM, Tom Lane wrote:
> >> (Of course, if we were to get rid of "Source code", the point
> >> would be moot ...)
>
> > I still think that having source code is useful for debugging, so I
> > left it
Michael Paquier writes:
> On Mon, Jul 11, 2016 at 12:42 AM, Tom Lane wrote:
>> (Of course, if we were to get rid of "Source code", the point
>> would be moot ...)
> I still think that having source code is useful for debugging, so I
> left it out. Note for the committer who will perhaps pick up
On Mon, Jul 11, 2016 at 12:42 AM, Tom Lane wrote:
> If we're keeping the "Source code" column, I'd be inclined to keep
> "Language" adjacent to that. When thinking of a function as a black
> box, both language and source code are implementation details; but
> all the other properties listed here
Michael Paquier writes:
>> - Reordering the columns, I'd suggest as follows):
>> -- Schema
>> -- Name
>> -- Result data type
>> -- Argument data types
>> -- Type
>> -- Language
>> -- Volatility
>> -- Parallel
>> -- Owner
>> -- Security
>> -- ACL
>> -- Source code
>> -- Description
If we're keepin
On Sat, Jul 9, 2016 at 8:12 AM, Michael Paquier
wrote:
> So to sum up:
> - Add "Parallel" column
> - Add ACLs
> - Reordering the columns, I'd suggest as follows):
> -- Schema
> -- Name
> -- Result data type
> -- Argument data types
> -- Type
> -- Language
> -- Volatility
> -- Parallel
> -- Owner
>
On Sat, Jul 9, 2016 at 4:02 AM, Pavel Stehule wrote:
>
>
> 2016-07-08 20:39 GMT+02:00 Tom Lane :
>>
>> Alvaro Herrera writes:
>> > As a separate concern, IMO having the source code in a \df+ column is
>> > almost completely useless.
>>
>> Good point. It works okay for C/internal functions, but i
2016-07-08 20:39 GMT+02:00 Tom Lane :
> Alvaro Herrera writes:
> > As a separate concern, IMO having the source code in a \df+ column is
> > almost completely useless.
>
> Good point. It works okay for C/internal functions, but in those cases
> it's usually redundant with the proname. For PL fu
Alvaro Herrera writes:
> As a separate concern, IMO having the source code in a \df+ column is
> almost completely useless.
Good point. It works okay for C/internal functions, but in those cases
it's usually redundant with the proname. For PL functions it's a disaster
formatting-wise, because t
Tom Lane wrote:
> Magnus Hagander writes:
> > On Friday, July 8, 2016, Michael Paquier wrote:
> >> Fujii-san has reminded me of the fact that we do not show in \df+ the
> >> parallel status of a function. The output of \df+ is already very
> >> large, so I guess that any people mentally sane alre
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Amit Kapila writes:
> > On Fri, Jul 8, 2016 at 5:27 PM, Michael Paquier
> > wrote:
> >> Okay. Here we go. I named the column for the parallel information
> >> "Parallelism".
>
> > Another option could be to name it as Parallel Mode.
>
> I'd go with just
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Magnus Hagander writes:
> > On Friday, July 8, 2016, Michael Paquier wrote:
> >> Fujii-san has reminded me of the fact that we do not show in \df+ the
> >> parallel status of a function. The output of \df+ is already very
> >> large, so I guess that any pe
Amit Kapila writes:
> On Fri, Jul 8, 2016 at 5:27 PM, Michael Paquier
> wrote:
>> Okay. Here we go. I named the column for the parallel information
>> "Parallelism".
> Another option could be to name it as Parallel Mode.
I'd go with just "Parallel", to keep it from being noticeably wider than
Magnus Hagander writes:
> On Friday, July 8, 2016, Michael Paquier wrote:
>> Fujii-san has reminded me of the fact that we do not show in \df+ the
>> parallel status of a function. The output of \df+ is already very
>> large, so I guess that any people mentally sane already use it with
>> the exp
On Fri, Jul 8, 2016 at 5:27 PM, Michael Paquier
wrote:
> On Fri, Jul 8, 2016 at 4:04 PM, Magnus Hagander wrote:
>> On Friday, July 8, 2016, Michael Paquier wrote:
>>>
>>> Hi all,
>>>
>>> Fujii-san has reminded me of the fact that we do not show in \df+ the
>>> parallel status of a function. The
On Fri, Jul 8, 2016 at 4:04 PM, Magnus Hagander wrote:
> On Friday, July 8, 2016, Michael Paquier wrote:
>>
>> Hi all,
>>
>> Fujii-san has reminded me of the fact that we do not show in \df+ the
>> parallel status of a function. The output of \df+ is already very
>> large, so I guess that any peo
2016-07-08 9:00 GMT+02:00 Michael Paquier :
> Hi all,
>
> Fujii-san has reminded me of the fact that we do not show in \df+ the
> parallel status of a function. The output of \df+ is already very
> large, so I guess that any people mentally sane already use it with
> the expanded display mode, and
On Friday, July 8, 2016, Michael Paquier wrote:
> Hi all,
>
> Fujii-san has reminded me of the fact that we do not show in \df+ the
> parallel status of a function. The output of \df+ is already very
> large, so I guess that any people mentally sane already use it with
> the expanded display mode
Hi all,
Fujii-san has reminded me of the fact that we do not show in \df+ the
parallel status of a function. The output of \df+ is already very
large, so I guess that any people mentally sane already use it with
the expanded display mode, and it may not matter adding more
information.
Thoughts abo
76 matches
Mail list logo
