Re: Ancient comment in rules.sgml

[Tatsuo Ishii]

>> Ok, I will remove the comment in all supported branches (after next
>> minor releases are out). Patch attached.
> 
> +1.  Looks fine to me.

Done.

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

Re: dblink_error_message return value

[Joe Conway]

On 10/2/18 8:45 AM, Joe Conway wrote:
> On 09/25/2018 03:58 PM, Joe Conway wrote:
>> On 09/25/2018 01:50 PM, Joe Conway wrote:
>>> On 08/08/2018 11:57 AM, Tom Lane wrote:
 =?utf-8?q?PG_Doc_comments_form?=  writes:
> The following documentation comment has been logged on the website:
> Documentation says:
 
> Return Value
> Returns last error message, or an empty string if there has been no error 
> in
> this connection.
> Which is invalid.
> Actually it returns 'OK' string if no error was raised.
 
 Good catch!  The code's quite clear about it, but the SGML docs need
 fixed.
>>> 
>>> 
>>> As mentioned on the nearby thread, will fix. I suppose this ought to be
>>> back-patched.
>>> 
>>> 
> Secondly
> dblink_is_busy must be first called to make dblink_error_message returns 
> an
> error message. (Tested on 9.6.9)
 
 Meh.  I see what you're getting at here, I think, but that seems like a
 completely wrong/misleading statement of the issue.  Joe, can you think of
 better phraseology?
>>> 
>>> Maybe a note, something like this?
>>> 
>>> When asynchronous queries are initiated by dblink_send_query(), the
>>> error message associated with the connection might not get updated until
>>> the server's response message is consumed. This typically means that
>>> dblink_is_busy() or dblink_get_result() should be called prior to
>>> dblink_error_message(), so that any error generated by the asynchronous
>>> query() will be visible.
>>> 
>> 
>> And now with the corresponding patch attached.
>> 
>> Thoughts/comments?
> 
> 
> Going once, going twice, ...
> (if no complaints will commit soon)


Well, maybe not so soon,  but now done.

Joe

-- 
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development



signature.asc
Description: OpenPGP digital signature

Re: Tutorial section of documentation: enhancements needed

[Thomas Munro]

On Fri, Feb 15, 2019 at 12:57 PM Jonathan S. Katz  wrote:
> On 2/12/19 3:06 AM, Lætitia Avrot wrote:
> > To me, there are 2 options:
> > - either, we change the "Tutorial" name of that chapter, so millenials
> > don't think they will find a step by step doc on how to install,
> > configure and connect to Postgres and add a tutorial page (the name can
> > be changed) on the postgresql.org  website
>
> I don't know if we need to change the name as much as it needs some
> rewriting. Perhaps the whole section is simplified to a "getting
> started" that gets people to download, install, and run PostgreSQL in
> their desired environment, and then the basic commands to get started
> (which I think we do a decent job of that portion?)

I was just wondering about creating a "how to test a patch" Wiki page.
Something to point people at, instead of writing out this sort of
thing in emails:

https://www.postgresql.org/message-id/CAEepm%3D1P0WD_g%3DELNmBJFhwKuCjYZOi4p4rutKj3kw7QneLB2A%40mail.gmail.com

The "Tools Sets" part of our documentation already gives how-to style
"apt-get this and that" instructions for various OSes.

As for the people using Windows who want to contribute, it sounds like
we need to fix PostgreSQL so that it works when you build it on WSL
(based on a report I heard that it doesn't work if you do that today,
at least with Ubuntu on WSL).  Then they could use the same super
short how-to-get-start guides as everyone else (I think the guide for
setting up native Windows development tools would be considerably
longer, since AFAIK you can't yet do something as easy as "apt-get foo
bar baz" and start hacking, but I don't know).

-- 
Thomas Munro
http://www.enterprisedb.com