Thread: [PATCH] Psql List Languages
Hi,,
My job, I maintainer some postgres server for clients. We have
many PL/(Java, Perl, Ruby, Python, R) and to more easy
administration, I worked new little psql attribute to list languages
com shorcurt/function \dL.
postgres@darkside:/media/disk/devel/pg$ bin/psql -U postgres test
psql (8.4devel)
Type "help" for help.
test=# \dL
List of languages
Name | Owner | Procedural Language | Trusted | Call
Handler | Validator
----------+----------+---------------------+------------+---------------------+-------------------------
c | postgres | No | Unstrusted |
| fmgr_c_validator
internal | postgres | No | Unstrusted |
| fmgr_internal_validator
plperl | postgres | Yes | Trusted |
plperl_call_handler | plperl_validator
sql | postgres | No | Trusted |
| fmgr_sql_validator
(4 rows)
test=#
I know that this moment is inappropriate to submit patch, with the
discussions about features for 8.4. But, if can added for commitfest
to 8.5 version. I'm appreciate.
Regards,
--
Fernando Ike
http://www.midstorm.org/~fike/weblog
Attachment
Hi, On Fri, Jan 30, 2009 at 3:03 PM, Fernando Ike <fike@midstorm.org> wrote: > Hi,, > > My job, I maintainer some postgres server for clients. We have > many PL/(Java, Perl, Ruby, Python, R) and to more easy > administration, I worked new little psql attribute to list languages > com shorcurt/function \dL. [..] > I know that this moment is inappropriate to submit patch, with the > discussions about features for 8.4. But, if can added for commitfest > to 8.5 version. I'm appreciate. I update patch for added gettext fields and change spaces/tab to 4 spaces. :) Cheers, -- Fernando Ike
Attachment
On Mon, Feb 02, 2009 at 11:29:51AM -0200, Fernando Ike wrote: > Hi, > > > On Fri, Jan 30, 2009 at 3:03 PM, Fernando Ike <fike@midstorm.org> wrote: > > Hi,, > > > > My job, I maintainer some postgres server for clients. We have > > many PL/(Java, Perl, Ruby, Python, R) and to more easy > > administration, I worked new little psql attribute to list languages > > com shorcurt/function \dL. > [..] > > I know that this moment is inappropriate to submit patch, with the > > discussions about features for 8.4. But, if can added for commitfest > > to 8.5 version. I'm appreciate. > > I update patch for added gettext fields and change spaces/tab to 4 spaces. :) +1 for adding this :) Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
Fernando Ike wrote: > I know that this moment is inappropriate to submit patch, with the > discussions about features for 8.4. But, if can added for commitfest > to 8.5 version. I'm appreciate. Yes, please add it to the first 8.5 commit fest. You can edit the wiki yourself.
On Monday 02 February 2009 15:29:51 Fernando Ike wrote: > Hi, > > On Fri, Jan 30, 2009 at 3:03 PM, Fernando Ike <fike@midstorm.org> wrote: > > Hi,, > > > > My job, I maintainer some postgres server for clients. We have > > many PL/(Java, Perl, Ruby, Python, R) and to more easy > > administration, I worked new little psql attribute to list languages > > com shorcurt/function \dL. > > [..] > > > I know that this moment is inappropriate to submit patch, with the > > discussions about features for 8.4. But, if can added for commitfest > > to 8.5 version. I'm appreciate. > > I update patch for added gettext fields and change spaces/tab to 4 > spaces. :) Looks good, but needs documentation and tab-complete.c updates, it seems. And you should revisit this patch to make it consistent with the S flag that was added to most \d commands. For example, \dL would show only user-added languages, but \dLS would include c, internal, and sql.
Peter Eisentraut <peter_e@gmx.net> writes:
> Looks good, but needs documentation and tab-complete.c updates, it seems. And
> you should revisit this patch to make it consistent with the S flag that was
> added to most \d commands. For example, \dL would show only user-added
> languages, but \dLS would include c, internal, and sql.
Another recent change in the \d support is that commands are expected to
work (as best they can) for all server versions back to 7.4. I didn't
look to see if this patch needs any fixes for that, but it's something
to keep in mind while reviewing.
regards, tom lane
Em Thu, 02 Jul 2009 15:27:33 -0400
Tom Lane <tgl@sss.pgh.pa.us> escreveu:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Looks good, but needs documentation and tab-complete.c updates, it
> > seems. And you should revisit this patch to make it consistent
> > with the S flag that was added to most \d commands. For example,
> > \dL would show only user-added languages, but \dLS would include c,
> > internal, and sql.
>
> Another recent change in the \d support is that commands are expected
> to work (as best they can) for all server versions back to 7.4. I
> didn't look to see if this patch needs any fixes for that, but it's
> something to keep in mind while reviewing.
I applied the Tom Lane and Peter considerations, but I had that
remove one column (Owner) of out command \dL to compatibility with 7.4
version. The command \dLS output:
test=# \dLS
List of languages
Name | Procedural Language | Trusted | Call Handler |
Validator
----------+---------------------+-----------+----------------------+
-------------------------
c | Untrusted | Untrusted | |
fmgr_c_validator
internal | Untrusted | Untrusted | |
fmgr_internal_validator
plperl | Trusted | Trusted | plperl_call_handler |
plperl_validator
plpgsql | Trusted | Trusted | plpgsql_call_handler |
plpgsql_validator
pltcl | Trusted | Trusted | pltcl_call_handler |
sql | Untrusted | Trusted | |
fmgr_sql_validator
(6 rows)
test=#
Comments?
Best Regards,
--
Fernando Ike
Attachment
On Thursday 16 July 2009 00:38:31 Fernando Ike de Oliveira wrote: > I applied the Tom Lane and Peter considerations, but I had that > remove one column (Owner) of out command \dL to compatibility with 7.4 > version. The mandate is to work as best as they can with older versions, not to provide only the feature set that works the same across old versions. The correct behavior should be to show the owner column if the server version supports it.
On Thu, Jul 16, 2009 at 10:41 AM, Peter Eisentraut<peter_e@gmx.net> wrote: > On Thursday 16 July 2009 00:38:31 Fernando Ike de Oliveira wrote: >> I applied the Tom Lane and Peter considerations, but I had that >> remove one column (Owner) of out command \dL to compatibility with 7.4 >> version. > > The mandate is to work as best as they can with older versions, not to provide > only the feature set that works the same across old versions. The correct > behavior should be to show the owner column if the server version supports it. Thanks for comment, Peter Follow new version patch, now with version postgresql version. Regards, -- Fernando Ike
Attachment
On Friday 17 July 2009 18:26:31 Fernando Ike wrote: > Follow new version patch, now with version postgresql version. 1) This is obviously wrong: CASE WHEN l.lanispl = 't' THEN 'Trusted' WHEN l.lanispl = 'f' THEN 'Untrusted' END 2) It may be better to use lanispl to determine whether a language is a system object or not. It's kind of obscure, but pg_dump does it that way, so it'd at least be consistent. 3) Your code does processSQLNamePattern(), but neither the help nor the documentation mention that \dL accepts a pattern. A pattern for listing languages might be overkill, but at least the documentation needs to match what the code attempts to do. 4) Instead of LEFT JOIN pg_catalog.pg_proc p on l.lanplcallfoid = p.oid etc, just cast the oid field to regprocedure. See examples elsewhere in describe.c. Please submit an updated patch.
On Sun, Jul 19, 2009 at 4:00 AM, Peter Eisentraut<peter_e@gmx.net> wrote: > Please submit an updated patch. Fernando, If you would like to have this change committed during this CommitFest, please submit an updated patch ASAP. Otherwise, you can resubmit for the next CommitFest in September. Thanks, ...Robert
On Thu, Jul 23, 2009 at 2:23 AM, Robert Haas<robertmhaas@gmail.com> wrote: > If you would like to have this change committed during this > CommitFest, please submit an updated patch ASAP. Otherwise, you can > resubmit for the next CommitFest in September. You know, I don't think we have any rules against people responding to patches submitted outside commitfest periods... -- greg http://mit.edu/~gsstark/resume.pdf
On Wed, Jul 22, 2009 at 9:35 PM, Greg Stark<gsstark@mit.edu> wrote: > On Thu, Jul 23, 2009 at 2:23 AM, Robert Haas<robertmhaas@gmail.com> wrote: >> If you would like to have this change committed during this >> CommitFest, please submit an updated patch ASAP. Otherwise, you can >> resubmit for the next CommitFest in September. > > You know, I don't think we have any rules against people responding to > patches submitted outside commitfest periods... I never suggested otherwise. In fact, I think it works much better when people DO respond to patches submitted outside CommitFests. What's your point? ...Robert
On Wed, Jul 22, 2009 at 9:43 PM, Robert Haas<robertmhaas@gmail.com> wrote: > On Wed, Jul 22, 2009 at 9:35 PM, Greg Stark<gsstark@mit.edu> wrote: >> On Thu, Jul 23, 2009 at 2:23 AM, Robert Haas<robertmhaas@gmail.com> wrote: >>> If you would like to have this change committed during this >>> CommitFest, please submit an updated patch ASAP. Otherwise, you can >>> resubmit for the next CommitFest in September. >> >> You know, I don't think we have any rules against people responding to >> patches submitted outside commitfest periods... > > I never suggested otherwise. In fact, I think it works much better > when people DO respond to patches submitted outside CommitFests. > What's your point? To follow up on that thought a little more... The patch author is certainly free to resubmit the patch at any time, and Peter (or any other committer) can commit it at any time, and may well do so. However, as far as the CommitFest process is concerned, we need to wrap things up within a finite time period that is not very long, and that can only happen if both reviews and resubmits happen in a timely fashion, so, since I've been tapped to manage this CommitFest, I'm trying to do what I can to keep on top of that. If my email struck you as rude, I certainly apologize for that. I'm trying really hard to be efficient about this without stepping on anyone's feelings, but that's a fine line to walk and I'm not sure I'll always be on the right side of it. Also, as a practical matter, while patches CAN get committed at any given time, one of the purposes of CommitFests, at least AIUI, is to give reviewers and committers a break from dealing with other people's patches. In other words, when it is NOT time for a CommitFest, as Tom put it, people shouldn't feel guilty about working on their own patches rather than reviewing. When it IS time for a CommitFest, they should. So the time when patches are *most likely* to be committed is during a CommitFest, and that is why I think there would be a benefit to the author of this patch in resubmitting it soon. I am trying to introduce something of a procedural change from the last CommitFest in that I think that the deadline for any particular patch to be resubmitted should be based at least in part on when it was reviewed, and not just on how many days we "have left" in the CommitFest, to avoid a huge pile of resubmissions just before some arbitrary cutoff, which then creates an unsupportable burden for reviewers and committers, or else just makes the CommitFest drag on and on. I think that's pretty reasonable. In fact, it's far MORE reasonable than what we did last time, where patches that got reviewed early sat around and were resubmitted at a very liesurely pace over a period of months, while other patches that got reviewed late got looked at once (or maybe twice) and then punted. Hopefully that seems reasonable - if not, let's discuss (perhaps after changing to a new thread). ...Robert
On Thu, Jul 23, 2009 at 3:11 AM, Robert Haas<robertmhaas@gmail.com> wrote: > > If my email struck you as rude, I certainly apologize for that. I'm > trying really hard to be efficient about this without stepping on > anyone's feelings, but that's a fine line to walk and I'm not sure > I'll always be on the right side of it. I didn't think your email was rude at all. Just that it could be (mis)construed to mean that if a patch isn't committed now the only time they'll get feedback again is next commitfest. -- greg http://mit.edu/~gsstark/resume.pdf
On Wed, Jul 22, 2009 at 9:23 PM, Robert Haas<robertmhaas@gmail.com> wrote: > On Sun, Jul 19, 2009 at 4:00 AM, Peter Eisentraut<peter_e@gmx.net> wrote: >> Please submit an updated patch. > > If you would like to have this change committed during this > CommitFest, please submit an updated patch ASAP. Otherwise, you can > resubmit for the next CommitFest in September. As this patch has not been updated, I am moving it to "Returned with Feedback". ...Robert