Re: PostgreSQL pollutes the file system

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Christoph Berg <myon(at)debian(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>, Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>, Andreas Karlsson <andreas(at)proxel(dot)se>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, eldmannen(at)gmail(dot)com, mark(dot)kirkwood(at)catalyst(dot)net(dot)nz, Michael Paquier <michael(at)paquier(dot)xyz>, Chris Travers <chris(dot)travers(at)adjust(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Euler Taveira <euler(at)timbira(dot)com(dot)br>, rjuju123(at)gmail(dot)com, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: PostgreSQL pollutes the file system
Date: 2019-03-29 19:01:30
Message-ID: CAFj8pRAFpZcDGL5i1wMQiHZ43y5Qd=22=+2vTCFOrak_mrUxjw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-pkg-debian

pá 29. 3. 2019 v 19:50 odesílatel Christoph Berg <myon(at)debian(dot)org> napsal:

> Re: Tom Lane 2019-03-29 <19517(dot)1553876700(at)sss(dot)pgh(dot)pa(dot)us>
> > >> Or perhaps better, allow pg_ctl to grow new subcommands for those
> > >> tasks?
> >
> > > We'd need to be careful to somehow delineate commands that need access
> > > to the data directory / run locally on the server from the ones that
> > > just needs a client connection.
> >
> > Hmm, that's a good point: to put it in terms that make sense to a
> > packager, it'd no longer be clear whether pg_ctl belongs in the
> > server package or the client package.
>
> True, and putting end-user commands like "create database" into the
> same admin tool like "stop", "promote", and "kill" feels both wrong
> and dangerous to me. It would also cause people to wonder why "pg_ctl
> -h remotehost stop" doesn't work.
>
> > I'm still not thrilled with wedging in these things as options
> > to psql though: its command line semantics are overly complicated
> > already, when you consider things like multiple -c and -f options.
> > I mean, somebody might think it's a feature to be able to do
> >
> > psql --createuser alice --createuser bob -c 'some command' -f
> somefile
> >
> > but I don't.
>
> Ack. (Otoh, just processing all arguments after another might be
> well-defined, and not too hard?)
>
> > Maybe if we want to merge these things into one executable,
> > it should be a new one. "pg_util createrole bob" ?
>
> "pg" is unfortunately already taken :(
>
> Fwiw, let's please keep supporting "createuser". Creating login roles
> is more common than non-login ones, and having to type "createrole
> --login bob" is cumbersome and will cause endless support requests by
> confused users.
>
> Other idea: If we don't want to reinvent a new tool, how about
> supporting prepared statements in psql?
>
> psql -c 'create user %i' --args 'bob w. space'
>

Prepared statements cannot be DDL commands.

But psql has safe escaping via :"xxx" notation. So some like

psql -c 'create role :"role"' -v role='my role' ...

But what I know the psql variables are not evaluated for -c query

Pavel

>
> Christoph
>
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Shaun Thomas 2019-03-29 19:25:03 Re: [PATCH] Incremental sort (was: PoC: Partial sort)
Previous Message Christoph Berg 2019-03-29 18:50:31 Re: PostgreSQL pollutes the file system

Browse pgsql-pkg-debian by date

  From Date Subject
Next Message Joe Conway 2019-03-29 19:32:57 Re: PostgreSQL pollutes the file system
Previous Message Christoph Berg 2019-03-29 18:50:31 Re: PostgreSQL pollutes the file system