Robert Haas wrote:
> On Wed, Jul 21, 2010 at 11:06 PM, David Christensen
> wrote:
> >
> > On Jul 21, 2010, at 12:31 PM, Alvaro Herrera wrote:
> >
> >> Excerpts from Peter Eisentraut's message of mi? jul 21 10:24:26 -0400 2010:
> >>> On tis, 2010-07-20 at 11:48 -0400, Robert Haas wrote:
> It'
Simon Riggs wrote:
> On Tue, 2010-07-20 at 09:05 -0400, Robert Haas wrote:
> > On Tue, Jul 20, 2010 at 8:21 AM, Simon Riggs wrote:
> > > On Tue, 2010-07-20 at 07:49 -0400, Robert Haas wrote:
> > >> A further point is that it's very difficult to
> > >> keep track of progress if the CF page reflects
Kevin Grittner wrote:
> > We should be giving authors as much leeway as possible, or they
> > may not come back.
>
> One phenomenon I've noticed is that sometimes a patch is submitted
> because an end user has solved their own problem for themselves, but
> wishes to share the solution with the co
On Wed, Jul 21, 2010 at 11:06 PM, David Christensen wrote:
>
> On Jul 21, 2010, at 12:31 PM, Alvaro Herrera wrote:
>
>> Excerpts from Peter Eisentraut's message of mié jul 21 10:24:26 -0400 2010:
>>> On tis, 2010-07-20 at 11:48 -0400, Robert Haas wrote:
It's tempting to propose making .psqlrc
On Jul 21, 2010, at 12:31 PM, Alvaro Herrera wrote:
> Excerpts from Peter Eisentraut's message of mié jul 21 10:24:26 -0400 2010:
>> On tis, 2010-07-20 at 11:48 -0400, Robert Haas wrote:
>>> It's tempting to propose making .psqlrc apply only in interactive
>>> mode, period. But that would be an
Excerpts from Peter Eisentraut's message of mié jul 21 10:24:26 -0400 2010:
> On tis, 2010-07-20 at 11:48 -0400, Robert Haas wrote:
> > It's tempting to propose making .psqlrc apply only in interactive
> > mode, period. But that would be an incompatibility with previous
> > releases, and I'm not s
On Wed, 2010-07-21 at 17:24 +0300, Peter Eisentraut wrote:
> On tis, 2010-07-20 at 11:48 -0400, Robert Haas wrote:
> > It's tempting to propose making .psqlrc apply only in interactive
> > mode, period. But that would be an incompatibility with previous
> > releases, and I'm not sure it's the beha
On Wed, Jul 21, 2010 at 11:31 AM, David Christensen wrote:
>
> On Jul 21, 2010, at 9:42 AM, Robert Haas wrote:
>
>> On Wed, Jul 21, 2010 at 10:24 AM, Peter Eisentraut wrote:
>>> On tis, 2010-07-20 at 11:48 -0400, Robert Haas wrote:
It's tempting to propose making .psqlrc apply only in intera
On Jul 21, 2010, at 9:42 AM, Robert Haas wrote:
> On Wed, Jul 21, 2010 at 10:24 AM, Peter Eisentraut wrote:
>> On tis, 2010-07-20 at 11:48 -0400, Robert Haas wrote:
>>> It's tempting to propose making .psqlrc apply only in interactive
>>> mode, period. But that would be an incompatibility with
On Wed, Jul 21, 2010 at 10:24 AM, Peter Eisentraut wrote:
> On tis, 2010-07-20 at 11:48 -0400, Robert Haas wrote:
>> It's tempting to propose making .psqlrc apply only in interactive
>> mode, period. But that would be an incompatibility with previous
>> releases, and I'm not sure it's the behavio
On tis, 2010-07-20 at 11:48 -0400, Robert Haas wrote:
> It's tempting to propose making .psqlrc apply only in interactive
> mode, period. But that would be an incompatibility with previous
> releases, and I'm not sure it's the behavior we want, either.
What is a use case for having .psqlrc be rea
On Jul 20, 2010, at 2:18 PM, Alvaro Herrera wrote:
> Excerpts from Robert Haas's message of mar jul 20 11:48:29 -0400 2010:
>
>>> That seems sub-optimal; I can see people wanting to use this feature to do
>>> something like:
>>>
>>> psql -c 'set work_mem = blah' -f script.sql
>>>
>>> and then
Excerpts from Robert Haas's message of mar jul 20 11:48:29 -0400 2010:
> > That seems sub-optimal; I can see people wanting to use this feature to do
> > something like:
> >
> > psql -c 'set work_mem = blah' -f script.sql
> >
> > and then being surprised when it works differently than just `psql
On Tue, Jul 20, 2010 at 12:08 PM, Mark Wong wrote:
> On Tue, Jul 20, 2010 at 4:06 AM, Robert Haas wrote:
>> On Tue, Jul 20, 2010 at 3:20 AM, Simon Riggs wrote:
>>> On Mon, 2010-07-19 at 23:40 -0400, Robert Haas wrote:
>>>
Since it has been over a month since this review was posted and no ne
On Tue, Jul 20, 2010 at 4:06 AM, Robert Haas wrote:
> On Tue, Jul 20, 2010 at 3:20 AM, Simon Riggs wrote:
>> On Mon, 2010-07-19 at 23:40 -0400, Robert Haas wrote:
>>
>>> Since it has been over a month since this review was posted and no new
>>> version of the patch has appeared, I think we should
On Tue, Jul 20, 2010 at 11:23 AM, David Christensen wrote:
>> Well, IIRC, one of -c and -f suppresses psqlrc, and the other does
>> not. This doesn't seem very consistent to me, but I'm not sure
>> there's much to be done about it at this point. I guess if you use
>> whichever one suppresses psq
On Jul 20, 2010, at 9:05 AM, Robert Haas wrote:
> On Tue, Jul 20, 2010 at 10:00 AM, David Christensen
> wrote:
>> Sorry for the delays in response. This is fine; I think there are some
>> semantic questions that should still be resolved at this point, particularly
>> if we're moving toward s
On Tue, Jul 20, 2010 at 10:00 AM, David Christensen wrote:
> Sorry for the delays in response. This is fine; I think there are some
> semantic questions that should still be resolved at this point, particularly
> if we're moving toward supporting multiple -c and -f lines as expressed (an
> ide
On Jul 19, 2010, at 10:40 PM, Robert Haas wrote:
> On Wed, Jun 23, 2010 at 9:22 AM, Robert Haas wrote:
>> On Wed, Jun 23, 2010 at 9:17 AM, gabrielle wrote:
>>> On Mon, Jun 21, 2010 at 6:16 PM, Robert Haas wrote:
Well, that might be a good idea, too, but my expectation is that:
On Tue, Jul 20, 2010 at 9:23 AM, Kevin Grittner
wrote:
> Robert Haas wrote:
>
>> we gain something quite specific and tangible, namely, the
>> expectation that patch authors will stay on top of their patches
>> if they want them reviewed by the community.
>
> Barring some operational emergency he
Simon Riggs wrote:
> I don't think so. We can assume people wrote a patch because they
> want it included in Postgres. Bumping them doesn't help them or
> us, since there is always an issue other than wish-to-complete.
> Not everybody is able to commit time in the way we do and we
> should respe
On Tue, 2010-07-20 at 09:05 -0400, Robert Haas wrote:
> On Tue, Jul 20, 2010 at 8:21 AM, Simon Riggs wrote:
> > On Tue, 2010-07-20 at 07:49 -0400, Robert Haas wrote:
> >> A further point is that it's very difficult to
> >> keep track of progress if the CF page reflects a whole bunch of
> >> suppos
Robert Haas wrote:
> we gain something quite specific and tangible, namely, the
> expectation that patch authors will stay on top of their patches
> if they want them reviewed by the community.
Barring some operational emergency here, I'll be reviewing the
status of all the open patches in the
On Tue, Jul 20, 2010 at 8:21 AM, Simon Riggs wrote:
> On Tue, 2010-07-20 at 07:49 -0400, Robert Haas wrote:
>> A further point is that it's very difficult to
>> keep track of progress if the CF page reflects a whole bunch of
>> supposedly "Waiting on Author" patches that are really quite
>> thorou
On Tue, 2010-07-20 at 07:49 -0400, Robert Haas wrote:
> A further point is that it's very difficult to
> keep track of progress if the CF page reflects a whole bunch of
> supposedly "Waiting on Author" patches that are really quite
> thoroughly dead.
True, but the point under discussion is what t
On Tue, Jul 20, 2010 at 7:41 AM, Simon Riggs wrote:
> So focus your effort by leaving this alone until the end of the CF.
> Actively terminating things early doesn't help at all with the review
> work you mention above, but it looks good if we are measuring "cases
> resolved per day". Are we measu
On Tue, 2010-07-20 at 07:06 -0400, Robert Haas wrote:
> To me, the definition of a fair shake is that people get 4-5 days to
> respond to review comments. This patch has had 33. It's not unfair
> to anyone to say, you know, since you didn't get around to updating
> this patch for over a month, yo
On Tue, Jul 20, 2010 at 3:20 AM, Simon Riggs wrote:
> On Mon, 2010-07-19 at 23:40 -0400, Robert Haas wrote:
>
>> Since it has been over a month since this review was posted and no new
>> version of the patch has appeared, I think we should mark this patch
>> as Returned with Feedback.
>
> Mark pos
On Mon, 2010-07-19 at 23:40 -0400, Robert Haas wrote:
> Since it has been over a month since this review was posted and no new
> version of the patch has appeared, I think we should mark this patch
> as Returned with Feedback.
Mark posted a new patch 6 days ago, AFAICS.
Not sure I see any benefi
On Wed, Jun 23, 2010 at 9:22 AM, Robert Haas wrote:
> On Wed, Jun 23, 2010 at 9:17 AM, gabrielle wrote:
>> On Mon, Jun 21, 2010 at 6:16 PM, Robert Haas wrote:
>>> Well, that might be a good idea, too, but my expectation is that:
>>>
>>> psql -f one -f two -f three
>>>
>>> ought to behave in a ma
On Jun 23, 2010, at 5:36 PM, Mark Wong wrote:
> On Jun 22, 2010, at 1:34 AM, Simon Riggs wrote:
>
>> On Mon, 2010-06-21 at 20:53 -0400, Robert Haas wrote:
>>> On Mon, Jun 21, 2010 at 7:51 PM, gabrielle wrote:
On Thu, 2010-06-17 at 14:50 -0400, Alvaro Herrera asked:
> How does it play wi
On Jun 22, 2010, at 1:34 AM, Simon Riggs wrote:
> On Mon, 2010-06-21 at 20:53 -0400, Robert Haas wrote:
>> On Mon, Jun 21, 2010 at 7:51 PM, gabrielle wrote:
>>> On Thu, 2010-06-17 at 14:50 -0400, Alvaro Herrera asked:
How does it play with ON_ERROR_STOP/ROLLBACK?
>>>
>>> With ON_ERROR_STOP=
On Wed, Jun 23, 2010 at 9:17 AM, gabrielle wrote:
> On Mon, Jun 21, 2010 at 6:16 PM, Robert Haas wrote:
>> Well, that might be a good idea, too, but my expectation is that:
>>
>> psql -f one -f two -f three
>>
>> ought to behave in a manner fairly similar to:
>>
>> cat one two three > all
>> psql
On Mon, Jun 21, 2010 at 6:16 PM, Robert Haas wrote:
> Well, that might be a good idea, too, but my expectation is that:
>
> psql -f one -f two -f three
>
> ought to behave in a manner fairly similar to:
>
> cat one two three > all
> psql -f all
>
> and it sounds like with this patch that's far fro
On Mon, 2010-06-21 at 20:53 -0400, Robert Haas wrote:
> On Mon, Jun 21, 2010 at 7:51 PM, gabrielle wrote:
> > On Thu, 2010-06-17 at 14:50 -0400, Alvaro Herrera asked:
> >> How does it play with ON_ERROR_STOP/ROLLBACK?
> >
> > With ON_ERROR_STOP=ON, psql issues an error when it encounters one,
> >
On Mon, Jun 21, 2010 at 9:13 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> So none of the above sounds like desired behavior to me... is that just me?
>
> Yeah, I'm not really thrilled with this.. I mentioned earlier what I
> thought would be a useful feature (basica
* Robert Haas (robertmh...@gmail.com) wrote:
> So none of the above sounds like desired behavior to me... is that just me?
Yeah, I'm not really thrilled with this.. I mentioned earlier what I
thought would be a useful feature (basically, a switch which would
ignore the main psqlrc and turn on th
On Mon, Jun 21, 2010 at 7:51 PM, gabrielle wrote:
> On Thu, 2010-06-17 at 14:50 -0400, Alvaro Herrera asked:
>> How does it play with ON_ERROR_STOP/ROLLBACK?
>
> With ON_ERROR_STOP=ON, psql issues an error when it encounters one,
> stops processing the file that contains the error, and then contin
On Thu, 2010-06-17 at 14:50 -0400, Alvaro Herrera asked:
> How does it play with ON_ERROR_STOP/ROLLBACK?
With ON_ERROR_STOP=ON, psql issues an error when it encounters one,
stops processing the file that contains the error, and then continues
to process any remaining files.
I'm still investigatin
On Thu, 2010-06-17 at 14:50 -0400, Alvaro Herrera wrote:
> Excerpts from Mark Wong's message of mié jun 16 23:54:52 -0400 2010:
>
> > ==Usability review==
> > Read what the patch is supposed to do, and consider:
> > Does the patch actually implement that?
>
> How does it play with ON_ERROR_STOP/R
Excerpts from Mark Wong's message of mié jun 16 23:54:52 -0400 2010:
> ==Usability review==
> Read what the patch is supposed to do, and consider:
> Does the patch actually implement that?
How does it play with ON_ERROR_STOP/ROLLBACK?
--
Álvaro Herrera
The PostgreSQL Company - Command Prompt,
Hi David,
At a pdxpug gathering, we took a look at your patch to psql for
supporting multiple -f's and put together some feedback:
REVIEW: Patch: support multiple -f options
https://commitfest.postgresql.org/action/patch_view?id=286
==Submission review==
Is the patch in context diff format?
On Sun, 2010-03-07 at 16:37 +0100, Magnus Hagander wrote:
> With your interleave, you mean things like "psql -f first.sql -f - -f
> second.sql"? That does sound like it could be handy - and also really
> dangerous :-)
Multiple -f support would be a good thing.
As would mixed -f and -c options.
W
On Mon, Mar 8, 2010 at 1:39 AM, David Christensen wrote:
>
> On Mar 7, 2010, at 9:22 AM, Tom Lane wrote:
>
>> Magnus Hagander writes:
>>>
>>> 2010/3/6 Tom Lane :
The analogy I was thinking about was psql -X, but I agree that it's
not obvious why this shouldn't be thought of as an a
On Mar 7, 2010, at 9:22 AM, Tom Lane wrote:
Magnus Hagander writes:
2010/3/6 Tom Lane :
The analogy I was thinking about was psql -X, but I agree that it's
not obvious why this shouldn't be thought of as an additional -f
file.
Uh, I don't follow. When we use -f, we'll run the script and
Magnus Hagander wrote:
> >> Also, "-f -" and just "psql" behaves different today (for example, in
> >> the showing of startup banners).
> >
> > Yes, there would be some things to think about there, which is why it's
> > a topic for a new devel cycle rather than something to shoehorn in
> > after th
2010/3/7 Tom Lane :
> Magnus Hagander writes:
>> 2010/3/7 Tom Lane :
>>> If we were going to support multiple -f options, it would be sensible
>>> to interpret "-f -" as "read from stdin until EOF".
>
>> Right, that would work. Though it would be a lot more user-unfriendly
>> for such a simple thi
Magnus Hagander writes:
> 2010/3/7 Tom Lane :
>> If we were going to support multiple -f options, it would be sensible
>> to interpret "-f -" as "read from stdin until EOF".
> Right, that would work. Though it would be a lot more user-unfriendly
> for such a simple thing, IMHO.
If the issue had
2010/3/7 Tom Lane :
> Magnus Hagander writes:
>> 2010/3/6 Tom Lane :
>>> The analogy I was thinking about was psql -X, but I agree that it's
>>> not obvious why this shouldn't be thought of as an additional -f file.
>
>> Uh, I don't follow. When we use -f, we'll run the script and then
>> exit. Th
Magnus Hagander writes:
> 2010/3/6 Tom Lane :
>> The analogy I was thinking about was psql -X, but I agree that it's
>> not obvious why this shouldn't be thought of as an additional -f file.
> Uh, I don't follow. When we use -f, we'll run the script and then
> exit. The whole point is to run it a
2010/3/6 Tom Lane :
> Peter Eisentraut writes:
>> I can see the environment variable variant as an analogy to BASH_ENV,
>> but what is the use case for the --psqlrc option? Wouldn't it be easier
>> and more useful to just be able to process more than one file, say by
>> specifying -f more than on
Peter Eisentraut writes:
> I can see the environment variable variant as an analogy to BASH_ENV,
> but what is the use case for the --psqlrc option? Wouldn't it be easier
> and more useful to just be able to process more than one file, say by
> specifying -f more than once?
The analogy I was thi
On fre, 2010-03-05 at 11:30 +0100, Magnus Hagander wrote:
> > Do you have a use-case where --psqlrc would be more useful than an
> > environment variable, or is it *only* bike-shedding? ;)
>
> Just to be clear, the code difference isn't very large. Attached is a
> patch that does both PSQLRC and -
2010/3/5 Tom Lane :
> Magnus Hagander writes:
>> 2010/3/5 David Christensen :
>>> My bikeshed has a --psqlrc path/to/file, but +1 on the idea.
>
>> Do you have a use-case where --psqlrc would be more useful than an
>> environment variable, or is it *only* bike-shedding? ;)
>
> The env variable sol
Magnus Hagander writes:
> 2010/3/5 David Christensen :
>> My bikeshed has a --psqlrc path/to/file, but +1 on the idea.
> Do you have a use-case where --psqlrc would be more useful than an
> environment variable, or is it *only* bike-shedding? ;)
The env variable solution seems a bit surprising t
2010/3/5 Magnus Hagander :
> 2010/3/5 David Christensen :
>>
>> On Mar 4, 2010, at 4:00 PM, Magnus Hagander wrote:
>>
>>> I've now for the second time found myself wanting to specify an
>>> explicit psqlrc file instead of just parsing ~/.psqlrc, so attached is
>>> a patch that accepts the PSQLRC en
2010/3/5 David Christensen :
>
> On Mar 4, 2010, at 4:00 PM, Magnus Hagander wrote:
>
>> I've now for the second time found myself wanting to specify an
>> explicit psqlrc file instead of just parsing ~/.psqlrc, so attached is
>> a patch that accepts the PSQLRC environment variable to control which
On Mar 4, 2010, at 4:00 PM, Magnus Hagander wrote:
I've now for the second time found myself wanting to specify an
explicit psqlrc file instead of just parsing ~/.psqlrc, so attached is
a patch that accepts the PSQLRC environment variable to control which
psqlrc file is used.
Any objections to
I've now for the second time found myself wanting to specify an
explicit psqlrc file instead of just parsing ~/.psqlrc, so attached is
a patch that accepts the PSQLRC environment variable to control which
psqlrc file is used.
Any objections to this (obviously including documentation - this is
just
59 matches
Mail list logo
