Thread: Re: [BUGS] First experiences with Postgresql 7.0

Re: [BUGS] First experiences with Postgresql 7.0

From
Peter Eisentraut
Date:
Well, don't I look stupid here. Once upon a time I recall to have fixed
exactly this issue, apparently it snuck back in.

If you run psql in non-interactive mode the psqlrc file shouldn't be read
at all. Unless people want that flag, but I don't like that better.

Perhaps this is a good time to ask when and how any fix to this should be
applied.


On Wed, 23 Feb 2000, Rolf Grossmann wrote:

> There is another problem with the regression tests: If the user running the
> tests has a .psqlrc file all regression tests fail, because commands from
> that file are echoed to the result file. Additionally, it a transaction
> is started from that file, regression tests fail, because they include tests
> for error cases and a transaction needs to be aborted after an error.
> 
> A possible solution would probably be to add a flag to psql that inhibits
> reading the .psqlrc file and using that flag with the regression tests.
> 
> On a related note (not a bug of course ;))... would it be possible to add
> some option to psql (or even libpq?) to always keep a transaction active?
> 
> Bye, Rolf
> 
> ************
> 
> 

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden



Re: [HACKERS] Re: [BUGS] First experiences with Postgresql 7.0

From
Bruce Momjian
Date:
> Well, don't I look stupid here. Once upon a time I recall to have fixed
> exactly this issue, apparently it snuck back in.
> 
> If you run psql in non-interactive mode the psqlrc file shouldn't be read
> at all. Unless people want that flag, but I don't like that better.
> 
> Perhaps this is a good time to ask when and how any fix to this should be
> applied.
> 
> 

I see the same problem here.  Also, the regression tests required me to
define PGLIB.

--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: [HACKERS] Re: [BUGS] First experiences with Postgresql 7.0

From
Tom Lane
Date:
Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
> If you run psql in non-interactive mode the psqlrc file shouldn't be read
> at all. Unless people want that flag, but I don't like that better.

> Perhaps this is a good time to ask when and how any fix to this should be
> applied.

This is arguably a bug fix, so you needn't worry about it being beta
phase.  However, there seems to be some doubt about exactly how it
*should* work, so you should hold off until there is consensus.

I take it you are considering "only read psqlrc if stdin is a tty",
rather than providing a switch-selectable choice.  I think that might
be too inflexible.  The regression tests clearly need to be able to
disregard psqlrc, but ordinary users will very likely want to write
scripts that depend on their psqlrc.  (For sure, we will get bug reports
"this works by hand but not in a script" that trace back to psqlrc
settings or lack of 'em.)

Using -f would work if you hadn't already overloaded it with another
meaning; but as you say I don't much want to add line numbers to all
the regress test expected outputs.  (That would mean that
adding/deleting lines in a test would create many bogus differences
further down in its output, which would be a pain in the neck for the
initial hand-validation of the changed output.)

So I vote for a switch that suppresses reading psqlrc ...
        regards, tom lane


Re: [HACKERS] Re: [BUGS] First experiences with Postgresql 7.0

From
Bruce Momjian
Date:
> Using -f would work if you hadn't already overloaded it with another
> meaning; but as you say I don't much want to add line numbers to all
> the regress test expected outputs.  (That would mean that
> adding/deleting lines in a test would create many bogus differences
> further down in its output, which would be a pain in the neck for the
> initial hand-validation of the changed output.)
> 
> So I vote for a switch that suppresses reading psqlrc ...
> 

Yes, but are there cases where we would want psqlrc values set?  Should
we specifically set all the variables ourselves on startup, just
over-riding what is in psqlrc?

--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: [HACKERS] Re: [BUGS] First experiences with Postgresql 7.0

From
Peter Eisentraut
Date:
On Thu, 24 Feb 2000, Tom Lane wrote:

> > Perhaps this is a good time to ask when and how any fix to this should be
> > applied.
> 
> This is arguably a bug fix, so you needn't worry about it being beta
> phase.

I'm not sure how this works now: Do I just commit it to the tree, so it
will be in when, say, beta2 gets generated?

> I take it you are considering "only read psqlrc if stdin is a tty",

This is how shells work, that's always my default decision for unchartered
territory. (Of course psql is not a shell, but that's why we're discussing
...)

> Using -f would work if you hadn't already overloaded it with another
> meaning;

Huh, "-f" is not a new option. "-f" is different from "<" because of two
reasons: 1) if they were the same, we wouldn't need one of them, and 2) a
program should behave the same independent of what kind of device its
standard input comes from. (That's why "<" doesn't print out error
messages with line numbers.) This is an ideal state of course.

[5 min later ...]

Ah, a tcsh user! ;) I could go for an -X option to suppress reading the
startup file, with default being that it is read in any mode. A pretty
dump option letter, but not all that far-fetched.

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden



Re: [HACKERS] Re: [BUGS] First experiences with Postgresql 7.0

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Yes, but are there cases where we would want psqlrc values set?  Should
> we specifically set all the variables ourselves on startup, just
> over-riding what is in psqlrc?

No.  In the first place, we've already got a dozen or two SET variables
(and the list keeps changing); do you really want to reset all of those
in each regress test?  In the second place, a psqlrc script could screw
things up in more creative ways than just issuing SET commands.  IIRC,
Rolf's original example was a psqlrc that issued a BEGIN to leave the
system in an open-transaction state.  In the third place, the psql echo
output from any commands issued by psqlrc would itself be enough to
cause bogus "failures" of all the tests.

One advantage of using a switch is that if someone *did* want to
experiment with regress test behavior with non-default settings,
he could set up a psqlrc file and then remove that switch from
the regression driver script.  Of course he'd have to ignore a
lot of bogus differences...
        regards, tom lane


Re: [HACKERS] Re: [BUGS] First experiences with Postgresql 7.0

From
Peter Eisentraut
Date:
On Thu, 24 Feb 2000, Bruce Momjian wrote:

> I see the same problem here.  Also, the regression tests required me to
> define PGLIB.

Is that because of createlang or initdb or both? Which regression driver?

-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden



Re: [HACKERS] Re: [BUGS] First experiences with Postgresql 7.0

From
Bruce Momjian
Date:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Yes, but are there cases where we would want psqlrc values set?  Should
> > we specifically set all the variables ourselves on startup, just
> > over-riding what is in psqlrc?
> 
> No.  In the first place, we've already got a dozen or two SET variables
> (and the list keeps changing); do you really want to reset all of those
> in each regress test?  In the second place, a psqlrc script could screw
> things up in more creative ways than just issuing SET commands.  IIRC,
> Rolf's original example was a psqlrc that issued a BEGIN to leave the
> system in an open-transaction state.  In the third place, the psql echo
> output from any commands issued by psqlrc would itself be enough to
> cause bogus "failures" of all the tests.
> 

Yes, I see.  Just asking.

--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: [HACKERS] Re: [BUGS] First experiences with Postgresql 7.0

From
Tom Lane
Date:
Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
>> This is arguably a bug fix, so you needn't worry about it being beta
>> phase.

> I'm not sure how this works now: Do I just commit it to the tree, so it
> will be in when, say, beta2 gets generated?

Right.  No real difference in commit procedures at this point.

At some point after the release, we will set up a branch for REL_7.0,
and after that, ordinary commits will only apply to new development
for 7.1, not to the stable release branch.  But no need to worry about
that for now.

> Ah, a tcsh user! ;) I could go for an -X option to suppress reading the
> startup file, with default being that it is read in any mode. A pretty
> dump option letter, but not all that far-fetched.

Works for me...
        regards, tom lane


Re: [HACKERS] Re: [BUGS] First experiences with Postgresql 7.0

From
Bruce Momjian
Date:
> On Thu, 24 Feb 2000, Bruce Momjian wrote:
> 
> > I see the same problem here.  Also, the regression tests required me to
> > define PGLIB.
> 
> Is that because of createlang or initdb or both? Which regression driver?

See later message.  createlang is causing it.

--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: [HACKERS] Re: [BUGS] First experiences with Postgresql 7.0

From
Lamar Owen
Date:
Peter Eisentraut wrote:
> 
> On Thu, 24 Feb 2000, Bruce Momjian wrote:
> 
> > I see the same problem here.  Also, the regression tests required me to
> > define PGLIB.
> 
> Is that because of createlang or initdb or both? Which regression driver?

Createlang has done this for some time -- at least since I've been
packaging the RPM's with the regression tests.  I have had to define
PGLIB in regress.sh -- otherwise, createlang doesn't know where to find
the pl .so. As my 7.0 installation is at home, I can't check the 7.0
regress.sh from here -- however, the 6.5.x regress.sh did it's own PGLIB
definition.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


Re: [HACKERS] Re: [BUGS] First experiences with Postgresql 7.0

From
Bruce Momjian
Date:
> On Thu, 24 Feb 2000, Tom Lane wrote:
> 
> > > Perhaps this is a good time to ask when and how any fix to this should be
> > > applied.
> > 
> > This is arguably a bug fix, so you needn't worry about it being beta
> > phase.
> 
> I'm not sure how this works now: Do I just commit it to the tree, so it
> will be in when, say, beta2 gets generated?

Betas are not static releases.  We live in beta for over a month, with
people making changes to fix user problems.


--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: [HACKERS] Re: [BUGS] First experiences with Postgresql 7.0

From
Bruce Momjian
Date:
> Peter Eisentraut wrote:
> > 
> > On Thu, 24 Feb 2000, Bruce Momjian wrote:
> > 
> > > I see the same problem here.  Also, the regression tests required me to
> > > define PGLIB.
> > 
> > Is that because of createlang or initdb or both? Which regression driver?
> 
> Createlang has done this for some time -- at least since I've been
> packaging the RPM's with the regression tests.  I have had to define
> PGLIB in regress.sh -- otherwise, createlang doesn't know where to find
> the pl .so. As my 7.0 installation is at home, I can't check the 7.0
> regress.sh from here -- however, the 6.5.x regress.sh did it's own PGLIB
> definition.

For some reason, I didn't need it until recently.

--  Bruce Momjian                        |  http://www.op.net/~candle pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: [HACKERS] Re: [BUGS] First experiences with Postgresql 7.0

From
Rolf Grossmann
Date:
Hi,

on Thu, 24 Feb 2000 16:59:48 +0100 (MET) Peter Eisentraut wrote 
concerning "Re: [HACKERS] Re: [BUGS] First experiences with Postgresql 7.0 " something like this:

> (Of course psql is not a shell, but that's why we're discussing ...)

Now, be careful with this statement. Personally, I have already tried to
use psql as a shell and I think it would be really cool if you could just
write #!/path/to/psql -f to write sql scripts.
However, that would require psql to treat # as a comment starter and we're
moving away from SQL standards with that. So I'm a bit weary of suggesting
such a thing.

>> Using -f would work if you hadn't already overloaded it with another
>> meaning;

> [5 min later ...]

> Ah, a tcsh user! ;) I could go for an -X option to suppress reading the
> startup file, with default being that it is read in any mode. A pretty
> dump option letter, but not all that far-fetched.

Uhm ... my tcsh manual describes those options differently:
      -f  The shell ignores ~/.tcshrc, and thus starts faster.      -X  Is to -x as -V is to -v.

Of course, as we have noted above, psql is not a shell, so I wonder if
that's the way to go. Personally, I'd say just pick a letter.

Bye, Rolf


Re: [HACKERS] Re: [BUGS] First experiences with Postgresql 7.0

From
Tom Lane
Date:
Rolf Grossmann <grossman@securitas.net> writes:
>> (Of course psql is not a shell, but that's why we're discussing ...)

> Now, be careful with this statement. Personally, I have already tried to
> use psql as a shell and I think it would be really cool if you could just
> write #!/path/to/psql -f to write sql scripts.

[ straying off-topic ]

Have you tried pgbash?  I haven't, but it sounds pretty cool if you
think psql and your shell should be the same thing...
        regards, tom lane


Re: [HACKERS] Re: [BUGS] First experiences with Postgresql 7.0

From
Tom Lane
Date:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> PGLIB in regress.sh -- otherwise, createlang doesn't know where to find
>> the pl .so. As my 7.0 installation is at home, I can't check the 7.0
>> regress.sh from here -- however, the 6.5.x regress.sh did it's own PGLIB
>> definition.

> For some reason, I didn't need it until recently.

I have PGDATA and PGLIB defined in .profile for my postgres account,
so I wouldn't have noticed whether the regress tests need it or not :-(
Possibly the same is true for most of the other developers.

IIRC, "make all" to set up the regress tests also needs PGLIB to be set.
        regards, tom lane


Re: [HACKERS] Re: [BUGS] First experiences with Postgresql 7.0

From
The Hermit Hacker
Date:
On Thu, 24 Feb 2000, Peter Eisentraut wrote:

> On Thu, 24 Feb 2000, Tom Lane wrote:
> 
> > > Perhaps this is a good time to ask when and how any fix to this should be
> > > applied.
> > 
> > This is arguably a bug fix, so you needn't worry about it being beta
> > phase.
> 
> I'm not sure how this works now: Do I just commit it to the tree, so it
> will be in when, say, beta2 gets generated?

bug fixes, yes ... but posting a patch against the current beta1 as a sort
of "here's the fix" would be very appreciated.  




Re: [HACKERS] Re: [BUGS] First experiences with Postgresql 7.0

From
The Hermit Hacker
Date:
On Thu, 24 Feb 2000, Bruce Momjian wrote:

> > Using -f would work if you hadn't already overloaded it with another
> > meaning; but as you say I don't much want to add line numbers to all
> > the regress test expected outputs.  (That would mean that
> > adding/deleting lines in a test would create many bogus differences
> > further down in its output, which would be a pain in the neck for the
> > initial hand-validation of the changed output.)
> > 
> > So I vote for a switch that suppresses reading psqlrc ...
> > 
> 
> Yes, but are there cases where we would want psqlrc values set?  Should
> we specifically set all the variables ourselves on startup, just
> over-riding what is in psqlrc?

IMHO, the regression tests are based on a snapshot where psql is in a
'default state' ... why would we want psqlrc values set?

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 



Re: [HACKERS] Re: [BUGS] First experiences with Postgresql 7.0

From
Peter Eisentraut
Date:
On 2000-02-24, Rolf Grossmann mentioned:

> use psql as a shell and I think it would be really cool if you could just
> write #!/path/to/psql -f to write sql scripts.

I considered that briefly, but dismissed it equally fast. psql is a shell
to the PostgreSQL backend, if you will, not to the system. It's optimized
as a batch processor and for being called from shell scripts, not for
being a programming language of it's own. (In the future it would be nice
to have a PL/Pgsql based front-end available for that sort of stuff.)

> Uhm ... my tcsh manual describes those options differently:
> 
>        -f  The shell ignores ~/.tcshrc, and thus starts faster.
>        -X  Is to -x as -V is to -v.

I wasn't actually implying to have picked -X in accordance with tcsh, I
was just confused about how Tom talked about -f.


-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden



Re: [HACKERS] Re: [BUGS] First experiences with Postgresql 7.0

From
Peter Eisentraut
Date:
On 2000-02-24, Lamar Owen mentioned:

> Peter Eisentraut wrote:
> > 
> > On Thu, 24 Feb 2000, Bruce Momjian wrote:
> > 
> > > I see the same problem here.  Also, the regression tests required me to
> > > define PGLIB.
> > 
> > Is that because of createlang or initdb or both? Which regression driver?
> 
> Createlang has done this for some time

You must provide an -L (--pglib) option to createlang, just as for
initdb. I'm committing a fix for this.

-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden



Re: [HACKERS] Re: [BUGS] First experiences with Postgresql 7.0

From
Tom Lane
Date:
Peter Eisentraut <peter_e@gmx.net> writes:
>> Uhm ... my tcsh manual describes those options differently:
>> 
>> -f  The shell ignores ~/.tcshrc, and thus starts faster.
>> -X  Is to -x as -V is to -v.

> I wasn't actually implying to have picked -X in accordance with tcsh, I
> was just confused about how Tom talked about -f.

Oh, sorry, I just meant that -f already has one special behavior in
addition to just physically selecting the input source, namely
causing line numbers to get attached to error messages.  That's fine,
but adding two special behaviors that aren't really closely related
to the same switch is not so great.
        regards, tom lane


Re: [HACKERS] Re: [BUGS] First experiences with Postgresql 7.0

From
Rolf Grossmann
Date:
Hi,

on Fri, 25 Feb 2000 00:39:15 +0100 (CET) Peter Eisentraut wrote 
concerning "Re: [HACKERS] Re: [BUGS] First experiences with Postgresql 7.0 "
something like this:

>> use psql as a shell and I think it would be really cool if you could just
>> write #!/path/to/psql -f to write sql scripts.

> I considered that briefly, but dismissed it equally fast. psql is a shell
> to the PostgreSQL backend, if you will, not to the system. It's optimized
> as a batch processor and for being called from shell scripts, not for
> being a programming language of it's own. (In the future it would be nice
> to have a PL/Pgsql based front-end available for that sort of stuff.)

Well, if you're saying psql is a shell, then maybe we should consider moving
in that direction. Not everything that's called with #! is a shell to the
system. The most notable example is probably perl, but there are other
programs like sed or awk that are being used with #! but certainly nobody
ever considered using awk as a system shell ;)

As for the programming language: You're already going in that direction
by implementing something like pl/sql. Now if that was available from
psql you're already way down the programming language road.

Just some thoughts ...
Rolf