Обсуждение: Patch to add 'id'
Would someone please apply this patch to the website code so pglife (http://pglife.momjian.us/) can more easily scrape the current release numbers from the website? Thanks. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
Вложения
> On 10 Jun 2018, at 04:16, Bruce Momjian <bruce@momjian.us> wrote: > > Would someone please apply this patch to the website code so pglife > (http://pglife.momjian.us/) can more easily scrape the current release > numbers from the website? Thanks. While harmless enough, I’m not a huge fan of adding identifiers to the site which are not in use in the site code, such non-obvious external dependencies make the code harder to maintain. If you are using XPath expressions to access the values, would something like this on the versioning page suffice for what you’re after? //*[@id="pgContentWrap"]/table/tbody/tr/td[text()="Yes"]/../td[2] cheers ./daniel
On Sun, Jun 10, 2018 at 4:16 AM, Bruce Momjian <bruce@momjian.us> wrote:
Would someone please apply this patch to the website code so pglife
(http://pglife.momjian.us/) can more easily scrape the current release
numbers from the website? Thanks.
Uh, if you are looking to get the current release, why are you scraping the main webpage instead of using the structured format data already available at https://www.postgresql.org/versions.rss?
(Now granted, I think that link may have gone missing in the redesign, but your pglife thing predates that..)
Now, having staid that, we should probably consider having a structured format with more data in it. But doesn't that one actually have all you need?
On Jun 10, 2018, at 3:29 PM, Daniel Gustafsson <daniel@yesql.se> wrote:On 10 Jun 2018, at 04:16, Bruce Momjian <bruce@momjian.us> wrote:
Would someone please apply this patch to the website code so pglife
(http://pglife.momjian.us/) can more easily scrape the current release
numbers from the website? Thanks.
While harmless enough, I’m not a huge fan of adding identifiers to the site
which are not in use in the site code, such non-obvious external dependencies
make the code harder to maintain.
Yes, while I’d love to support the version feed into pglife, I’m a -1 in
general on this patch:
1. There was a glut of IDs in the old styles and I don’t want to
start adding more unless there is a specific reason necessary for
supporting functionality on pgweb itself.
2. Typically websites make “structured information” as such available
via APIs or other interfaces, which I believe Magnus points out in a different
reply is achievable via a RSS feed[1].
I don’t think we should be adding more classes/IDs just for structured
information in the markup unless it’s being used to support pgweb
itself, because as Daniel points out it does become a maintenance issue
(speaking from firsthand experience).
If we do want to have more “structured” resources, I’d suggest either more
feeds (which seems to be the current PostgreSQL way of making things
available). The reason I’m not suggesting as RESTful API is I don’t see
the need for one just yet, as that has its own maintainability issues.
Thanks,
Jonathan
[1] https://www.postgresql.org/versions.rss - appears to be working too! :-)
On Sun, Jun 10, 2018 at 4:16 AM, Bruce Momjian <bruce@momjian.us> wrote:Would someone please apply this patch to the website code so pglife
(http://pglife.momjian.us/) can more easily scrape the current release
numbers from the website? Thanks.Uh, if you are looking to get the current release, why are you scraping the main webpage instead of using the structured format data already available at https://www.postgresql.org/versions.rss?(Now granted, I think that link may have gone missing in the redesign, but your pglife thing predates that..)Now, having staid that, we should probably consider having a structured format with more data in it. But doesn't that one actually have all you need?
Hm...just expanding on his, perhaps we have a “Feeds” page that has a collection of all the different
feeds we offer?
Jonathan
On Sun, Jun 10, 2018 at 11:46 PM, Jonathan S. Katz <jkatz@postgresql.org> wrote:
On Sun, Jun 10, 2018 at 4:16 AM, Bruce Momjian <bruce@momjian.us> wrote:Would someone please apply this patch to the website code so pglife
(http://pglife.momjian.us/) can more easily scrape the current release
numbers from the website? Thanks.Uh, if you are looking to get the current release, why are you scraping the main webpage instead of using the structured format data already available at https://www.postgresql.org/versions.rss? (Now granted, I think that link may have gone missing in the redesign, but your pglife thing predates that..)Now, having staid that, we should probably consider having a structured format with more data in it. But doesn't that one actually have all you need?Hm...just expanding on his, perhaps we have a “Feeds” page that has a collection of all the differentfeeds we offer?
That would probably not be a bad idea. Though perhaps have it being something other than specifically feeds, if we want to for example add the ability to give a json (or xml or whatnot) page with fully structured version info etc. Unless we want to consider those as being separate things and apart -- but I think having them both on the same page would make sense.
On Sun, Jun 10, 2018 at 09:29:51PM +0200, Daniel Gustafsson wrote: > > On 10 Jun 2018, at 04:16, Bruce Momjian <bruce@momjian.us> wrote: > > > > Would someone please apply this patch to the website code so pglife > > (http://pglife.momjian.us/) can more easily scrape the current release > > numbers from the website? Thanks. > > While harmless enough, I’m not a huge fan of adding identifiers to the site > which are not in use in the site code, such non-obvious external dependencies > make the code harder to maintain. > > If you are using XPath expressions to access the values, would something like > this on the versioning page suffice for what you’re after? > > //*[@id="pgContentWrap"]/table/tbody/tr/td[text()="Yes"]/../td[2] > > cheers ./daniel What is the URL of the versioning page? This one? https://www.postgresql.org/about/featurematrix/ -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
> On 11 Jun 2018, at 23:24, Bruce Momjian <bruce@momjian.us> wrote: > > On Sun, Jun 10, 2018 at 09:29:51PM +0200, Daniel Gustafsson wrote: >>> On 10 Jun 2018, at 04:16, Bruce Momjian <bruce@momjian.us> wrote: >>> >>> Would someone please apply this patch to the website code so pglife >>> (http://pglife.momjian.us/) can more easily scrape the current release >>> numbers from the website? Thanks. >> >> While harmless enough, I’m not a huge fan of adding identifiers to the site >> which are not in use in the site code, such non-obvious external dependencies >> make the code harder to maintain. >> >> If you are using XPath expressions to access the values, would something like >> this on the versioning page suffice for what you’re after? >> >> //*[@id="pgContentWrap"]/table/tbody/tr/td[text()="Yes"]/../td[2] > > What is the URL of the versioning page? This one? > > https://www.postgresql.org/about/featurematrix/ I was looking at the Versioning Policy page under Support: https://www.postgresql.org/support/versioning/ cheers ./daniel
On Mon, Jun 11, 2018 at 11:36:48PM +0200, Daniel Gustafsson wrote: > > On 11 Jun 2018, at 23:24, Bruce Momjian <bruce@momjian.us> wrote: > > > > On Sun, Jun 10, 2018 at 09:29:51PM +0200, Daniel Gustafsson wrote: > >>> On 10 Jun 2018, at 04:16, Bruce Momjian <bruce@momjian.us> wrote: > >>> > >>> Would someone please apply this patch to the website code so pglife > >>> (http://pglife.momjian.us/) can more easily scrape the current release > >>> numbers from the website? Thanks. > >> > >> While harmless enough, I’m not a huge fan of adding identifiers to the site > >> which are not in use in the site code, such non-obvious external dependencies > >> make the code harder to maintain. > >> > >> If you are using XPath expressions to access the values, would something like > >> this on the versioning page suffice for what you’re after? > >> > >> //*[@id="pgContentWrap"]/table/tbody/tr/td[text()="Yes"]/../td[2] > > > > What is the URL of the versioning page? This one? > > > > https://www.postgresql.org/about/featurematrix/ > > I was looking at the Versioning Policy page under Support: > > https://www.postgresql.org/support/versioning/ Oh, yes, that would work, except I like links to the release notes which are on the main page. I ended up just adding a loop over the DIVs looking for H2 text "Latest Releases" and it worked just fine. Pglife is now fixed. Thanks. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
On Sun, Jun 10, 2018 at 09:40:20PM +0200, Magnus Hagander wrote: > On Sun, Jun 10, 2018 at 4:16 AM, Bruce Momjian <bruce@momjian.us> wrote: > > Would someone please apply this patch to the website code so pglife > (http://pglife.momjian.us/) can more easily scrape the current release > numbers from the website? Thanks. > > > Uh, if you are looking to get the current release, why are you scraping the > main webpage instead of using the structured format data already available at > https://www.postgresql.org/versions.rss? That doesn't contain an indication of which relases are supported. I could pull that from the git trees I keep, but using the website is more current. Anyway, I modified the Perl and it now works again. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +