Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> So that seems to tilt the decision towards exposing the conninfo_parse
>> function.  Joe, do you want to have a go at it, or shall I?

> Here's a first shot.

Hmm ... one problem with this is that the caller can't tell
failure-because-out-of-memory from failure-because-string-is-bogus.
That doesn't matter for your proposed dblink patch, but I had been
thinking of documenting that if someone wanted to get an error message
explaining just what was wrong with the conninfo string, they could
try to open a connection with it and use the resulting failure message.
But it's just barely conceivable that the PQconnect call *wouldn't* fail
because out-of-memory.  (Not very likely in a sequential application,
but definitely seems possible in a multithreaded app --- some other
thread could release memory meanwhile.)  Is it worth having the
PQconninfoParse function pass back the error message to avoid this
corner case?  The API would be a lot more ugly, perhaps

        int PQconninfoParse(const char *connstr,
                            PQconninfoOption **options,
                            char **errmsg)

        okay: *options is set, *errmsg is NULL, return true
        bogus string: *options is NULL, *errmsg is set, return false
        out of memory: both outputs NULL, return false

                        regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to