Обсуждение: Re: BUG #15706: Support Services page out of date
Em ter, 19 de mar de 2019 às 16:35, PG Bug reporting form <noreply@postgresql.org> escreveu: > > https://www.postgresql.org/support/professional_support/northamerica/ > > Has a LARGE number of out-of-date and incorrect listings. > [redirecting to www...] Should we ask for confirmation every x months? -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
On 3/20/19 1:55 PM, Euler Taveira wrote: > Em ter, 19 de mar de 2019 às 16:35, PG Bug reporting form > <noreply@postgresql.org> escreveu: >> >> https://www.postgresql.org/support/professional_support/northamerica/ >> >> Has a LARGE number of out-of-date and incorrect listings. >> > [redirecting to www...] Should we ask for confirmation every x months? I did an audit of it a few years back, we are due for another one (and something on my TODO for this year). When I did the audit, it took several weeks to review all of the listings, so without additional help, "every x months" is not reasonable. Additionally, it also depends what is "out of date" -- if they are companies that no longer exist, yes, the listing should be removed. If a company does not keep up to date the # of employees, or its offerings, etc., that's not something we can really control. Jonathan
Вложения
Em qua, 20 de mar de 2019 às 17:12, Jonathan S. Katz <jkatz@postgresql.org> escreveu: > > I did an audit of it a few years back, we are due for another one (and > something on my TODO for this year). When I did the audit, it took > several weeks to review all of the listings, so without additional help, > "every x months" is not reasonable. > Jonathan, I appreciate your effort. I'm suggesting an automated way to check the list (send an URL by email for confirmation). If there is no response, stop to show that company. Company can always enable it again. Periodic notification can encourage companies to keep their info up to date. I'm not volunteering to do the work. -- Euler Taveira Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
On 3/20/19 7:11 PM, Euler Taveira wrote: > Em qua, 20 de mar de 2019 às 17:12, Jonathan S. Katz > <jkatz@postgresql.org> escreveu: >> >> I did an audit of it a few years back, we are due for another one (and >> something on my TODO for this year). When I did the audit, it took >> several weeks to review all of the listings, so without additional help, >> "every x months" is not reasonable. >> > Jonathan, I appreciate your effort. I'm suggesting an automated way to > check the list (send an URL by email for confirmation). If there is no > response, stop to show that company. Company can always enable it > again. Periodic notification can encourage companies to keep their > info up to date. I'm not volunteering to do the work. Some of the pgweb folks have discussed doing that before; it's not a bad idea, and perhaps would cut down on some of the headaches. If we went down that route, I think we would want to borrow from some of the pgeu codebase, which I believe has reminder infrastructure set up, and then apply it to this. If we went down this path, it'd be good to apply it to products in the software catalog as well. Jonathan
Вложения
On Thu, Mar 21, 2019 at 1:20 AM Jonathan S. Katz <jkatz@postgresql.org> wrote:
On 3/20/19 7:11 PM, Euler Taveira wrote:
> Em qua, 20 de mar de 2019 às 17:12, Jonathan S. Katz
> <jkatz@postgresql.org> escreveu:
>>
>> I did an audit of it a few years back, we are due for another one (and
>> something on my TODO for this year). When I did the audit, it took
>> several weeks to review all of the listings, so without additional help,
>> "every x months" is not reasonable.
>>
> Jonathan, I appreciate your effort. I'm suggesting an automated way to
> check the list (send an URL by email for confirmation). If there is no
> response, stop to show that company. Company can always enable it
> again. Periodic notification can encourage companies to keep their
> info up to date. I'm not volunteering to do the work.
Some of the pgweb folks have discussed doing that before; it's not a bad
idea, and perhaps would cut down on some of the headaches.
That was in fact the original plan, nobody just got around to building it. There was even a db field for it in the early dev snapshots, but it was removed since it was never quite done.
The general idea was to just have a "last confirmed" timestamp field on each entry, and just stop showing any entries that have not been confirmed in <n> days/weeks/months/whatever. We can keep them around some extra time beyond that in case people come back to update them later of course.
If we went down that route, I think we would want to borrow from some of
the pgeu codebase, which I believe has reminder infrastructure set up,
and then apply it to this. If we went down this path, it'd be good to
apply it to products in the software catalog as well.
I think we pretty much have all the needed parts already. All that's needed is a "last reminded" field along with the "last onfirmed" one above, and decide on a schedule between those two for sending reminders.
Oh, and +1 for doing the same for products.
On Sunday, March 24, 2019 6:50 PM, Magnus Hagander <magnus@hagander.net> wrote:
On Thu, Mar 21, 2019 at 1:20 AM Jonathan S. Katz <jkatz@postgresql.org> wrote:Some of the pgweb folks have discussed doing that before; it's not a badidea, and perhaps would cut down on some of the headaches.That was in fact the original plan, nobody just got around to building it. There was even a db field for it in the early dev snapshots, but it was removed since it was never quite done.The general idea was to just have a "last confirmed" timestamp field on each entry, and just stop showing any entries that have not been confirmed in <n> days/weeks/months/whatever. We can keep them around some extra time beyond that in case people come back to update them later of course.
I think it makes sense to remove after a set timeout, if the user hasn't verified in 3 months (or some
other sufficiently long period) then the odds that the entry is out of date seems quite high.
Oh, and +1 for doing the same for products.
+1
cheers ./daniel
On 3/25/19 5:33 AM, Daniel Gustafsson wrote:
> On Sunday, March 24, 2019 6:50 PM, Magnus Hagander <magnus@hagander.net>
> wrote:
>> On Thu, Mar 21, 2019 at 1:20 AM Jonathan S. Katz <jkatz@postgresql.org
>> <mailto:jkatz@postgresql.org>> wrote:
>>
>> Some of the pgweb folks have discussed doing that before; it's not
>> a bad
>> idea, and perhaps would cut down on some of the headaches.
>>
>>
>> That was in fact the original plan, nobody just got around to building
>> it. There was even a db field for it in the early dev snapshots, but
>> it was removed since it was never quite done.
>>
>> The general idea was to just have a "last confirmed" timestamp field
>> on each entry, and just stop showing any entries that have not been
>> confirmed in <n> days/weeks/months/whatever. We can keep them around
>> some extra time beyond that in case people come back to update them
>> later of course.
>
> I think it makes sense to remove after a set timeout, if the user hasn't
> verified in 3 months (or some
> other sufficiently long period) then the odds that the entry is out of
> date seems quite high.
>
>> Oh, and +1 for doing the same for products.
>
> +1
So I had (made?) a chunk of uninterrupted time and went ahead and did a
manual scrub of the professional services page with a test for the
proposed above algorithm. Summary and details to follow:
Looking at the timestamp on some of the old moderation comments, it
turned out the last scrub was almost 5 years to the day. Oops, time flies :(
When looking at the listed services, the main thing I checked was did
the website that was linked to from the service indicate the
organization supported PostgreSQL or PostgreSQL-related product in some
way -- this made it a fairly low bar to clear. I bucked each service
into one of 3 categories:
1. OK: I was able to find their PostgreSQL offering
2. Send a Follow-up: Website was still active & looked like a technology
provider, but no clear indication of PostgreSQL offering. This I think
is the simulation of how the "please perform this update" automation
would work
3. Remove: website was dead / company did something completely different
/ site redirected me to things I would like to unsee. All the more
reason to scrub the data.
The scrub took me about 2 hours and change.
- 167 of the listings fell into category 1
- 28 required follow-ups (category 2) and I sent as such providing a
reasonable timeline to provide at least some update (one week)
- 39 fell into category 3 and were remove.
Based on the last time I did this, I think ~25% of the category 2
organizations will get back and make the necessary updates, so assume we
remove that much more.
Anyway, the data was much more stale than I thought it would be :( But
I'm not surprised, either.
This is also a long way of saying that I think we should proceed with
the solution to help automate this. After going through the painstaking
process again, I'd recommend it works kind of like this:
- An email goes out once every {6 months, 1 year} to the organizational
contact that says something like: "Hi, This is an automated check to
ensure your company is still an active PostgreSQL service provider.
Please click the URL provided to confirm. <UniqueURL> If you do not
confirm within 7 days, your listing will be unpublished"
- If user clicks URL, it is confirmed and the last_confirmed_date is set
to CURRENT_DATE
- If user does not click URL, we set the entry to unpublished. This
would put it into the moderator feed, and one of the pgweb moderators
can then take further action if need be.
Anyway, products needs a scrub as well, which I will try to block out
some time for in the coming days to handle those as well. Those should
hopefully not take as much time as they are a bit easier to verify.
Thanks,
Jonathan
Вложения
On Sat, Apr 27, 2019 at 5:48 AM Jonathan S. Katz <jkatz@postgresql.org> wrote:
On 3/25/19 5:33 AM, Daniel Gustafsson wrote:
> On Sunday, March 24, 2019 6:50 PM, Magnus Hagander <magnus@hagander.net>
> wrote:
>> On Thu, Mar 21, 2019 at 1:20 AM Jonathan S. Katz <jkatz@postgresql.org
>> <mailto:jkatz@postgresql.org>> wrote:
>>
>> Some of the pgweb folks have discussed doing that before; it's not
>> a bad
>> idea, and perhaps would cut down on some of the headaches.
>>
>>
>> That was in fact the original plan, nobody just got around to building
>> it. There was even a db field for it in the early dev snapshots, but
>> it was removed since it was never quite done.
>>
>> The general idea was to just have a "last confirmed" timestamp field
>> on each entry, and just stop showing any entries that have not been
>> confirmed in <n> days/weeks/months/whatever. We can keep them around
>> some extra time beyond that in case people come back to update them
>> later of course.
>
> I think it makes sense to remove after a set timeout, if the user hasn't
> verified in 3 months (or some
> other sufficiently long period) then the odds that the entry is out of
> date seems quite high.
>
>> Oh, and +1 for doing the same for products.
>
> +1
So I had (made?) a chunk of uninterrupted time and went ahead and did a
manual scrub of the professional services page with a test for the
proposed above algorithm. Summary and details to follow:
Thanks! That must've been a painful couple of hours :)
<snip>
This is also a long way of saying that I think we should proceed with
the solution to help automate this. After going through the painstaking
process again, I'd recommend it works kind of like this:
- An email goes out once every {6 months, 1 year} to the organizational
contact that says something like: "Hi, This is an automated check to
ensure your company is still an active PostgreSQL service provider.
Please click the URL provided to confirm. <UniqueURL> If you do not
confirm within 7 days, your listing will be unpublished"
7 days might be a bit on the short side. If someone is unlucky they get the notification while on vacation for example, and then they're delisted before they can even see it.
- If user clicks URL, it is confirmed and the last_confirmed_date is set
to CURRENT_DATE
- If user does not click URL, we set the entry to unpublished. This
would put it into the moderator feed, and one of the pgweb moderators
can then take further action if need be.
That's pretty close to my original thoughts around that, except I'd just delete them as step 3 and not bother the queue. I'm fine with de-listing it as well, as long as pgweb moderators are happy to handle that :) That would also take care of the scenario where the email bounces, by simply being able to ignore that fact and leave it up to the individual moderator to handle manually.
Anyway, products needs a scrub as well, which I will try to block out
some time for in the coming days to handle those as well. Those should
hopefully not take as much time as they are a bit easier to verify.
On 4/27/19 6:41 AM, Magnus Hagander wrote:
>
>
> On Sat, Apr 27, 2019 at 5:48 AM Jonathan S. Katz <jkatz@postgresql.org
> <mailto:jkatz@postgresql.org>> wrote:
> This is also a long way of saying that I think we should proceed with
> the solution to help automate this. After going through the painstaking
> process again, I'd recommend it works kind of like this:
>
> - An email goes out once every {6 months, 1 year} to the organizational
> contact that says something like: "Hi, This is an automated check to
> ensure your company is still an active PostgreSQL service provider.
> Please click the URL provided to confirm. <UniqueURL> If you do not
> confirm within 7 days, your listing will be unpublished"
>
>
> 7 days might be a bit on the short side. If someone is unlucky they get
> the notification while on vacation for example, and then they're
> delisted before they can even see it.
Well, that's why I suggested it gets de-listed, so one of us can
manually check and determine if indeed it should be delisted, or it's
the case of out-of-office, or a bad email address, etc.
> - If user clicks URL, it is confirmed and the last_confirmed_date is set
> to CURRENT_DATE
>
> - If user does not click URL, we set the entry to unpublished. This
> would put it into the moderator feed, and one of the pgweb moderators
> can then take further action if need be.
>
>
> That's pretty close to my original thoughts around that, except I'd just
> delete them as step 3 and not bother the queue. I'm fine with
> de-listing it as well, as long as pgweb moderators are happy to handle
> that :) That would also take care of the scenario where the email
> bounces, by simply being able to ignore that fact and leave it up to the
> individual moderator to handle manually.
I would de-list it. It's certainly easier for a moderator to check a few
of said entries vs. the whole slew.
> Anyway, products needs a scrub as well, which I will try to block out
> some time for in the coming days to handle those as well. Those should
> hopefully not take as much time as they are a bit easier to verify.
>
> Cool. Thanks!
NP, feels good to do some spring/fall cleaning :)
Jonathan
Вложения
On 4/26/19 11:48 PM, Jonathan S. Katz wrote: > On 3/25/19 5:33 AM, Daniel Gustafsson wrote: >> On Sunday, March 24, 2019 6:50 PM, Magnus Hagander <magnus@hagander.net> >> wrote: >>> On Thu, Mar 21, 2019 at 1:20 AM Jonathan S. Katz <jkatz@postgresql.org >>> <mailto:jkatz@postgresql.org>> wrote: >>> >>> Some of the pgweb folks have discussed doing that before; it's not >>> a bad >>> idea, and perhaps would cut down on some of the headaches. >>> >>> >>> That was in fact the original plan, nobody just got around to building >>> it. There was even a db field for it in the early dev snapshots, but >>> it was removed since it was never quite done. >>> >>> The general idea was to just have a "last confirmed" timestamp field >>> on each entry, and just stop showing any entries that have not been >>> confirmed in <n> days/weeks/months/whatever. We can keep them around >>> some extra time beyond that in case people come back to update them >>> later of course. >> >> I think it makes sense to remove after a set timeout, if the user hasn't >> verified in 3 months (or some >> other sufficiently long period) then the odds that the entry is out of >> date seems quite high. >> >>> Oh, and +1 for doing the same for products. OK, so I did the scrub for products. > The scrub took me about 2 hours and change. Fortunately, products are a bit more straightforward and did not take as long as services, though it was still at least an hour. So whatever system we put in place for services, I suggest the same for products There were 210 products listed at the beginning of the scrub. - 170 remain - 40 were removed as they did not exist + no obvious replacement / went to things I wish I could unsee. I would say this was more stale than I thought too, but given that there has not been a product scrub as long as I can remember, it's not as bad as the staleness of the services. Regardless, let's work on getting that system into place to help manage it so scrubs are less gargantuan tasks. Thanks, Jonathan
Вложения
> On 4/26/19 11:48 PM, Jonathan S. Katz wrote: >> On 3/25/19 5:33 AM, Daniel Gustafsson wrote: >>> On Sunday, March 24, 2019 6:50 PM, Magnus Hagander <magnus@hagander.net> >>> wrote: >>>> On Thu, Mar 21, 2019 at 1:20 AM Jonathan S. Katz <jkatz@postgresql.org >>>> <mailto:jkatz@postgresql.org>> wrote: >>>> >>>> Some of the pgweb folks have discussed doing that before; it's not >>>> a bad >>>> idea, and perhaps would cut down on some of the headaches. >>>> >>>> >>>> That was in fact the original plan, nobody just got around to building >>>> it. There was even a db field for it in the early dev snapshots, but >>>> it was removed since it was never quite done. >>>> >>>> The general idea was to just have a "last confirmed" timestamp field >>>> on each entry, and just stop showing any entries that have not been >>>> confirmed in <n> days/weeks/months/whatever. We can keep them around >>>> some extra time beyond that in case people come back to update them >>>> later of course. >>> >>> I think it makes sense to remove after a set timeout, if the user hasn't >>> verified in 3 months (or some >>> other sufficiently long period) then the odds that the entry is out of >>> date seems quite high. >>> >>>> Oh, and +1 for doing the same for products. > > OK, so I did the scrub for products. > >> The scrub took me about 2 hours and change. > > Fortunately, products are a bit more straightforward and did not take as > long as services, though it was still at least an hour. So whatever > system we put in place for services, I suggest the same for products > > There were 210 products listed at the beginning of the scrub. > > - 170 remain > - 40 were removed as they did not exist + no obvious replacement / went > to things I wish I could unsee. > > I would say this was more stale than I thought too, but given that there > has not been a product scrub as long as I can remember, it's not as bad > as the staleness of the services. > > Regardless, let's work on getting that system into place to help manage > it so scrubs are less gargantuan tasks. Are we working on this region only? https://www.postgresql.org/support/professional_support/northamerica/ Some of the companies listed in the northamerica page also appear in other regions (I only checked aisa though). I think companies removed from the northamerica region should also be removed from other regions as well unless they explicitly stat that they have different entities in the other regions. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
Re: BUG #15706: Support Services page out of date,Re: BUG #15706:Support Services page out of date
От
"Jonathan S. Katz"
Дата:
Hi Tatsuo, On 4/28/19 5:38 PM, Tatsuo Ishii wrote: >> On 4/26/19 11:48 PM, Jonathan S. Katz wrote: >>> On 3/25/19 5:33 AM, Daniel Gustafsson wrote: >>>> On Sunday, March 24, 2019 6:50 PM, Magnus Hagander <magnus@hagander.net> >>>> wrote: >>>>> On Thu, Mar 21, 2019 at 1:20 AM Jonathan S. Katz <jkatz@postgresql.org >>>>> <mailto:jkatz@postgresql.org>> wrote: >>>>> >>>>> Some of the pgweb folks have discussed doing that before; it's not >>>>> a bad >>>>> idea, and perhaps would cut down on some of the headaches. >>>>> >>>>> >>>>> That was in fact the original plan, nobody just got around to building >>>>> it. There was even a db field for it in the early dev snapshots, but >>>>> it was removed since it was never quite done. >>>>> >>>>> The general idea was to just have a "last confirmed" timestamp field >>>>> on each entry, and just stop showing any entries that have not been >>>>> confirmed in <n> days/weeks/months/whatever. We can keep them around >>>>> some extra time beyond that in case people come back to update them >>>>> later of course. >>>> >>>> I think it makes sense to remove after a set timeout, if the user hasn't >>>> verified in 3 months (or some >>>> other sufficiently long period) then the odds that the entry is out of >>>> date seems quite high. >>>> >>>>> Oh, and +1 for doing the same for products. >> >> OK, so I did the scrub for products. >> >>> The scrub took me about 2 hours and change. >> >> Fortunately, products are a bit more straightforward and did not take as >> long as services, though it was still at least an hour. So whatever >> system we put in place for services, I suggest the same for products >> >> There were 210 products listed at the beginning of the scrub. >> >> - 170 remain >> - 40 were removed as they did not exist + no obvious replacement / went >> to things I wish I could unsee. >> >> I would say this was more stale than I thought too, but given that there >> has not been a product scrub as long as I can remember, it's not as bad >> as the staleness of the services. >> >> Regardless, let's work on getting that system into place to help manage >> it so scrubs are less gargantuan tasks. > > Are we working on this region only? > https://www.postgresql.org/support/professional_support/northamerica/ I went through every organization that was listed, regardless of region. > Some of the companies listed in the northamerica page also appear in > other regions (I only checked aisa though). I think companies removed > from the northamerica region should also be removed from other regions > as well unless they explicitly stat that they have different entities > in the other regions. The pgweb schema allows for a professional service to be listed in all the regions it operates. I did not adjust that; I only removed organizations that were clearly no longer operating (based on above definition), and reached out to other orgs for clarifying questions. In the case of removal, the org was removed from _all_ regions. Thanks, Jonathan
Вложения
From: "Jonathan S. Katz" <jkatz@postgresql.org> Subject: Re: BUG #15706: Support Services page out of date,Re: BUG #15706: Support Services page out of date,Re: BUG #15706: Support Services page out of date,Re: BUG #15706: Support Services pageout of date Date: Sun, 28 Apr 2019 17:41:30 -0400 Message-ID: <da24e2b8-c633-90d5-0739-18bc7286ed16@postgresql.org>,<da24e2b8-c633-90d5-0739-18bc7286ed16@postgresql.org> > Hi Tatsuo, > > On 4/28/19 5:38 PM, Tatsuo Ishii wrote: >>> On 4/26/19 11:48 PM, Jonathan S. Katz wrote: >>>> On 3/25/19 5:33 AM, Daniel Gustafsson wrote: >>>>> On Sunday, March 24, 2019 6:50 PM, Magnus Hagander <magnus@hagander.net> >>>>> wrote: >>>>>> On Thu, Mar 21, 2019 at 1:20 AM Jonathan S. Katz <jkatz@postgresql.org >>>>>> <mailto:jkatz@postgresql.org>> wrote: >>>>>> >>>>>> Some of the pgweb folks have discussed doing that before; it's not >>>>>> a bad >>>>>> idea, and perhaps would cut down on some of the headaches. >>>>>> >>>>>> >>>>>> That was in fact the original plan, nobody just got around to building >>>>>> it. There was even a db field for it in the early dev snapshots, but >>>>>> it was removed since it was never quite done. >>>>>> >>>>>> The general idea was to just have a "last confirmed" timestamp field >>>>>> on each entry, and just stop showing any entries that have not been >>>>>> confirmed in <n> days/weeks/months/whatever. We can keep them around >>>>>> some extra time beyond that in case people come back to update them >>>>>> later of course. >>>>> >>>>> I think it makes sense to remove after a set timeout, if the user hasn't >>>>> verified in 3 months (or some >>>>> other sufficiently long period) then the odds that the entry is out of >>>>> date seems quite high. >>>>> >>>>>> Oh, and +1 for doing the same for products. >>> >>> OK, so I did the scrub for products. >>> >>>> The scrub took me about 2 hours and change. >>> >>> Fortunately, products are a bit more straightforward and did not take as >>> long as services, though it was still at least an hour. So whatever >>> system we put in place for services, I suggest the same for products >>> >>> There were 210 products listed at the beginning of the scrub. >>> >>> - 170 remain >>> - 40 were removed as they did not exist + no obvious replacement / went >>> to things I wish I could unsee. >>> >>> I would say this was more stale than I thought too, but given that there >>> has not been a product scrub as long as I can remember, it's not as bad >>> as the staleness of the services. >>> >>> Regardless, let's work on getting that system into place to help manage >>> it so scrubs are less gargantuan tasks. >> >> Are we working on this region only? >> https://www.postgresql.org/support/professional_support/northamerica/ > > I went through every organization that was listed, regardless of region. > >> Some of the companies listed in the northamerica page also appear in >> other regions (I only checked aisa though). I think companies removed >> from the northamerica region should also be removed from other regions >> as well unless they explicitly stat that they have different entities >> in the other regions. > > The pgweb schema allows for a professional service to be listed in all > the regions it operates. I did not adjust that; I only removed > organizations that were clearly no longer operating (based on above > definition), and reached out to other orgs for clarifying questions. In > the case of removal, the org was removed from _all_ regions. Great! That perfectly makes sense. BTW, how can companies listed on those pages update the descriptions? I see new registeration form: https://www.postgresql.org/account/services/new/ but fails to find update or removal form. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp
On 4/28/19 5:49 PM, Tatsuo Ishii wrote: > BTW, how can companies listed on those pages update the descriptions? > I see new registeration form: > https://www.postgresql.org/account/services/new/ > > but fails to find update or removal form. They should be listed here: https://www.postgresql.org/account/edit/services/ I did a quick check and it looks like the SRA OSS Inc. org is associated with the profile, so you should be able to click on the URL there and perform any updates. Thanks! Jonathan
Вложения
> On 4/28/19 5:49 PM, Tatsuo Ishii wrote: >> BTW, how can companies listed on those pages update the descriptions? >> I see new registeration form: >> https://www.postgresql.org/account/services/new/ >> >> but fails to find update or removal form. > > They should be listed here: > > https://www.postgresql.org/account/edit/services/ > > I did a quick check and it looks like the SRA OSS Inc. org is associated > with the profile, so you should be able to click on the URL there and > perform any updates. Thank you for letting know me. It would be nice if the link above is on: https://www.postgresql.org/support/professional_support/ with a comment something like: "If your company is already listed here and you want to update the descriptions, please click here." Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp