Even though many of the list members of [EMAIL PROTECTED]
suggest that the following is an expected behaviour, my experience in
other databases doesn't permit me accept it as such. I am putting this
for the kind consideration of this list
Description : I have two tables with the same data ,
Anoo Sivadasan Pillai wrote:
Even though many of the list members of [EMAIL PROTECTED]
suggest that the following is an expected behaviour, my experience in
other databases doesn't permit me accept it as such. I am putting this
for the kind consideration of this list
I think it's more of a
On Thu, Sep 27, 2007 at 02:48:52PM +0530, Anoo Sivadasan Pillai wrote:
Description : I have two tables with the same data , While I issue an
update command to increment the value of a unique field by 1, the
statement fails in one table and will succeed in the other table.
Following is the
Martijn van Oosterhout wrote:
On Thu, Sep 27, 2007 at 02:48:52PM +0530, Anoo Sivadasan Pillai wrote:
Description : I have two tables with the same data , While I issue an
update command to increment the value of a unique field by 1, the
statement fails in one table and will succeed in the
On Thu, Sep 27, 2007 at 12:15:24PM +0200, Lukas Kahwe Smith wrote:
It's been on the TODO list for at least 5 years...
Wow, I was not aware of this limitation. MySQL hacks around this issue
by allowing an ORDER BY in UPDATE (and DELETE) statements.
There is a similar workaround for postgres
Your pg_dump's actually invoke the pager? Are you manually starting
psql, then doing \i dumpfile? Why would you do that rather than psql
template1 dumpfile?
Because I'm a dork :-).
Seriously, sometimes it's useful.
The most useful reason (and I wish you could turn it on with psql
Larry Rosenman [EMAIL PROTECTED] writes:
On Mon, 11 Aug 2003, Bruce Momjian wrote:
Larry Rosenman wrote:
Can we modify pg_dumpall (or pg_dump?) to include a \pset pager off
to prevent the setval() calls from halting an interactive \i of the dump
file?
Your pg_dump's actually invoke the
Christopher Kings-Lynne writes:
The most useful reason (and I wish you could turn it on with psql file) is
the line number in the file where any errors occur.
psql -f file will do that.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of
--On Tuesday, August 12, 2003 09:30:39 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
Nope. There is no .psqlrc.
It seems to be new with 7.4cvs. (dunno about earlier 7.4), but it
definitely did NOT happen with 7.3.x
Hmph. There have been some changes in 7.4
Larry Rosenman [EMAIL PROTECTED] writes:
Nope. There is no .psqlrc.
It seems to be new with 7.4cvs. (dunno about earlier 7.4), but it definitely
did NOT happen with 7.3.x
Hmph. There have been some changes in 7.4 psql's pager support, but I
can't see anything there that looks like it would
On Mon, 11 Aug 2003, Bruce Momjian wrote:
Larry Rosenman wrote:
Can we modify pg_dumpall (or pg_dump?) to include a \pset pager off
to prevent the setval() calls from halting an interactive \i of the dump
file?
Your pg_dump's actually invoke the pager? Are you manually starting
psql,
Can we modify pg_dumpall (or pg_dump?) to include a \pset pager off
to prevent the setval() calls from halting an interactive \i of the dump
file?
Thanks,
LER
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US
Larry Rosenman wrote:
Can we modify pg_dumpall (or pg_dump?) to include a \pset pager off
to prevent the setval() calls from halting an interactive \i of the dump
file?
Your pg_dump's actually invoke the pager? Are you manually starting
psql, then doing \i dumpfile? Why would you do that
--On Monday, August 11, 2003 20:36:11 -0400 Tom Lane [EMAIL PROTECTED]
wrote:
Larry Rosenman [EMAIL PROTECTED] writes:
On Mon, 11 Aug 2003, Bruce Momjian wrote:
Larry Rosenman wrote:
Can we modify pg_dumpall (or pg_dump?) to include a \pset pager off
to prevent the setval() calls from halting
14 matches
Mail list logo
