Re: Path separator

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Path separator
Дата
Msg-id 49E19DFD.4010701@hagander.net
обсуждение исходный текст
Ответ на Re: Path separator  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Path separator  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> 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,
> because of de-staticizing so many functions.  I guess we could stick pg_
> prefixes on all of them.  That's a bit ugly; anybody have a better idea?

Not really.


> It might be that it'd be better to push a couple more of the simple
> path-munging functions (like join_path_components) over into the new
> file, so as to have a more logical division of responsibilities.
> In my mind the two key areas here are "path syntax knowledge" and
> "extracting absolute paths from environmental information".  The second
> part seems to be the one that doesn't belong on the frontend side.

What would be the gain there? To be able to re-static-ify for example
skip_drive? Or just a nicer division?

We should probably also consider moving get_home_path() over to the
frontend one, and get rid of the copy that's in fe-connect.c.


//Magnus



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: HashJoin w/option to unique-ify inner rel
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: [pgtranslation-translators] on gettext plural support