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 postg
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 othe
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
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 "kn
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 ,
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 Mail:
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
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 wo
--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
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 broadcast)-
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 actual
> > 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 Because I'm a dork :-).
>
> Seriously, sometimes it's useful.
The most useful reason (and I wish you could turn it on with psql < file)
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 halti
14 matches
Mail list logo