yeah, we have a couple of patches that aren't good... And I kind of
lost track of it waiting for feedback on my last question.
It's not a must-fix, but it'd be good to get better messages eventually.
//Magnus
2010/2/26 Bruce Momjian :
>
> I assume we never came to any conclusion on this.
>
> ---
I assume we never came to any conclusion on this.
---
Magnus Hagander wrote:
> Tom Lane wrote:
> > Magnus Hagander writes:
> >>> Answering myself here: the filesize for the "frontend only" part is
> >>> about 2k on this sys
Tom Lane wrote:
> Magnus Hagander writes:
>>> Answering myself here: the filesize for the "frontend only" part is
>>> about 2k on this system.
>
>> Long meeting, time for coding.. :-) Here's a rough patch. Is this about
>> what you had in mind?
>
> Hm, this seems to make the namespace pollution
Magnus Hagander writes:
>> Answering myself here: the filesize for the "frontend only" part is
>> about 2k on this system.
> Long meeting, time for coding.. :-) Here's a rough patch. Is this about
> what you had in mind?
Hm, this seems to make the namespace pollution problem worse not better,
be
I wrote:
> Since I'm the one who's hot about this, I'm willing to do the work.
Belay that ... I'll review your patch instead, later today sometime.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscriptio
Magnus Hagander writes:
> Tom Lane wrote:
>> The major stumbling block to doing either thing is not wishing to import
>> path.c into libpq. I think that the objection was partially code size
>> and partially namespace pollution (path.c doesn't use pg_ or similar
>> prefixes on its exported names)
Magnus Hagander wrote:
> Magnus Hagander wrote:
>>> The major stumbling block to doing either thing is not wishing to import
>>> path.c into libpq. I think that the objection was partially code size
>>> and partially namespace pollution (path.c doesn't use pg_ or similar
>>> prefixes on its export
Magnus Hagander wrote:
>> The major stumbling block to doing either thing is not wishing to import
>> path.c into libpq. I think that the objection was partially code size
>> and partially namespace pollution (path.c doesn't use pg_ or similar
>> prefixes on its exported names). The latter is no
Tom Lane wrote:
> Magnus Hagander writes:
>> Tom Lane wrote:
>>> In view of the way that canonicalize_path() works, I can't help thinking
>>> this is going in precisely the wrong direction.
>
>> In a way, yes. But canonicalize_path() runs only in the backend, and
>> this is only in the frontend.
Magnus Hagander writes:
> Tom Lane wrote:
>> In view of the way that canonicalize_path() works, I can't help thinking
>> this is going in precisely the wrong direction.
> In a way, yes. But canonicalize_path() runs only in the backend, and
> this is only in the frontend. I think the requirements
Tom Lane wrote:
> Magnus Hagander writes:
>> I've seen a couple of reports that the new SSL error messages on windows
>> look strange with paths the wrong way. For example:
>
>> root certificate file "C:\Documents and Settings\\Application
>> Data/postgresql/root.crt" does not exist.
>
>> The is
Magnus Hagander writes:
> I've seen a couple of reports that the new SSL error messages on windows
> look strange with paths the wrong way. For example:
> root certificate file "C:\Documents and Settings\\Application
> Data/postgresql/root.crt" does not exist.
> The issue being the mix of forwar
On Wed, Mar 18, 2009 at 9:24 AM, Magnus Hagander wrote:
> I've seen a couple of reports that the new SSL error messages on windows
> look strange with paths the wrong way. For example:
>
> root certificate file "C:\Documents and Settings\\Application
> Data/postgresql/root.crt" does not exist.
>
>
I've seen a couple of reports that the new SSL error messages on windows
look strange with paths the wrong way. For example:
root certificate file "C:\Documents and Settings\\Application
Data/postgresql/root.crt" does not exist.
The issue being the mix of forward and backwards slashes. Attached p
14 matches
Mail list logo
