Re: Proposing COPY .. WITH PERMISSIVE

Поиск
Список
Период
Сортировка
От dinesh kumar
Тема Re: Proposing COPY .. WITH PERMISSIVE
Дата
Msg-id CALnrH7rMf2jfrP=v==APbR8KUjwu_WueQDgaMSEwKpztDkQroQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Proposing COPY .. WITH PERMISSIVE  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
On Thu, Nov 12, 2015 at 4:35 AM, Michael Paquier <michael.paquier@gmail.com> wrote:
On Sat, Oct 3, 2015 at 1:43 PM, dinesh kumar wrote:
> We can also use "PROGRAM 'cat > Output.csv' " to achieve this "NO READ
> ACCESS", since the program is always running as a instance owner.
> Let me know your inputs and thoughts.

That's one way. And as PROGRAM presents the advantage to open the file
before the COPY has begun processing any tuples, the umask would be
set before writing any data to it, hence why complicating COPY with a
new option while we already have something to apply restrictions to
the output file? It seems that this patch is just an unnecessary
complication, and I doubt that we would want to change the default
behavior of 644 that has been here for ages.

Hi Michael,

Thanks for your inputs.

I am also against changing the default behavior. Since, I see, some advantages having 644.

As pg_file_write, and 'PROGRAM' uses it's instance owner umask for the output file, I believe,
we should also have the same umaks for the COPY too. I Could be wrong here, But I don't see
"PROGRAM" as an alternative to this. Since, we have a separate TO clause, which takes care about
dumping data into files.

Let me know, if I'm wrong here.

--
Michael



--

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

Предыдущее
От: Vik Fearing
Дата:
Сообщение: Re: psql: add \pset true/false
Следующее
От: Andres Freund
Дата:
Сообщение: Re: checkpointer continuous flushing