[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(at)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

Hi,

On Fri, Jan 30, 2009 at 3:03 PM, Fernando Ike <fike(at)midstorm(dot)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

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(at)midstorm(dot)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(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)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(at)midstorm(dot)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(at)gmx(dot)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(at)sss(dot)pgh(dot)pa(dot)us> escreveu:

> Peter Eisentraut <peter_e(at)gmx(dot)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

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(at)gmx(dot)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

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(at)gmx(dot)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(at)gmail(dot)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(at)mit(dot)edu> wrote:
> On Thu, Jul 23, 2009 at 2:23 AM, Robert Haas<robertmhaas(at)gmail(dot)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(at)gmail(dot)com> wrote:
> On Wed, Jul 22, 2009 at 9:35 PM, Greg Stark<gsstark(at)mit(dot)edu> wrote:
>> On Thu, Jul 23, 2009 at 2:23 AM, Robert Haas<robertmhaas(at)gmail(dot)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(at)gmail(dot)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(at)gmail(dot)com> wrote:
> On Sun, Jul 19, 2009 at 4:00 AM, Peter Eisentraut<peter_e(at)gmx(dot)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