I just cut and pasted someone's mac address:
patrimoine=# update ethernet set mac='00-00-39-AB-92-FO' where id=623;
UPDATE 1
patrimoine=# select mac from ethernet where id=623;
mac
---
00:00:39:ab:92:0f
(1 row)
Note the typo O instead of 0. I can see how that
Barry Lind [EMAIL PROTECTED] writes:
Below is the current behavior (based on a fresh pull from cvs this morning):
Current State ActionEnd State
ACon and NITset ACon ACon and NIT
set ACoff ACoff and IT*
Patrick Welche [EMAIL PROTECTED] writes:
I just cut and pasted someone's mac address:
patrimoine=# update ethernet set mac='00-00-39-AB-92-FO' where id=623;
UPDATE 1
patrimoine=# select mac from ethernet where id=623;
mac
---
00:00:39:ab:92:0f
(1 row)
I said:
Bruce was supposed to fix this. We agreed that a SET command would
never initiate a transaction block on its own. Looks like it's not
there yet ---
Now it is. Give it another try ...
regards, tom lane
---(end of
Gavin Sherry wrote:
On Sat, 12 Oct 2002, Joe Conway wrote:
Tom Lane wrote:
Hackers: we might reasonably fix this by doing a deep copy of the
relcache's trigger info during initResultRelInfo(); or we could fix it
by getting rid of ri_TrigDesc and re-fetching from the relcache every
- Forwarded message from Bruce Momjian [EMAIL PROTECTED] -
I don't know. Would you ask hackers list, and perhaps CC the author of
that patch.
---
Denis A Ustimenko wrote:
Bruce, why have all precise time
Tom Lane wrote:
Barry Lind [EMAIL PROTECTED] writes:
Below is the current behavior (based on a fresh pull from cvs this morning):
Current State ActionEnd State
ACon and NITset ACon ACon and NIT
set ACoff
Is it worth an initdb for 7.3b3 to fix this? I think we were already
considering forcing one for the command-tag issues, otherwise I'd
probably vote no. Comments?
Do we need an initdb to fix command tags? I thought that was just a
change in the Query structure.
Denis A Ustimenko wrote:
Bruce, why have all precise time calculations been droped out in 1.206? If there is
no
gettimeofday in win32?
gettimeofday was not portable to win32 (at least not that I could find) and
hence broke the win32 build of the clients.
Joe
---(end
Tom Lane wrote:
Bruno Wolff III [EMAIL PROTECTED] writes:
On Sat, Oct 12, 2002 at 12:43:37 +0300,
Antti Haapala [EMAIL PROTECTED] wrote:
What about copy? AFAIK, copy doesn't allow column names being specified,
so it's not purely aesthetic...
The SQL COPY command does (at least in
Tom Lane wrote:
Isn't this a bug?
regression=# create table FOO (f1 int);
CREATE TABLE
regression=# \copy FOO from stdin
ERROR: Relation FOO does not exist
\copy: ERROR: Relation FOO does not exist
regression=#
This happens because \copy takes the given table name and slaps
double
Bruce Momjian [EMAIL PROTECTED] writes:
Well, I thought I did it, and it did work on my limited number of test
cases. Seems you got it fully working.
Actually, it failed for me (and evidently for Barry) on exactly the test
case you posted along with the patch. You said
test= set autocommit
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Do we want to look at this as a bug (okay to fix for 7.3) or a new
feature (wait for 7.4)?
I don't think we can say \copy missing columns is a bug; we never had
it in previous release. Seems like a missing feature. The COPY schema
Gavin Sherry [EMAIL PROTECTED] writes:
On Sat, 12 Oct 2002, Joe Conway wrote:
Tom Lane wrote:
Hackers: we might reasonably fix this by doing a deep copy of the
relcache's trigger info during initResultRelInfo(); or we could fix it
by getting rid of ri_TrigDesc and re-fetching from the
On Mon, 14 Oct 2002, Tom Lane wrote:
I was wondering whether an ALTER TABLE command is really the right way
to approach this. If we had an ALTER-type command, presumably the
implication is that its effects would be global to all backends. But
the uses that I've seen for suspending trigger
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Do we need an initdb to fix command tags? I thought that was just a
change in the Query structure.
A change in Query struct breaks stored rules. Looks like initdb
material to me ...
Oh, I forgot about stored rules. Yep, that
On Sun, Oct 13, 2002 at 09:02:55PM -0700, Joe Conway wrote:
Denis A Ustimenko wrote:
Bruce, why have all precise time calculations been droped out in 1.206?
If there is no
gettimeofday in win32?
gettimeofday was not portable to win32 (at least not that I could find) and
hence broke the
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Do we want to look at this as a bug (okay to fix for 7.3) or a new
feature (wait for 7.4)?
I don't think we can say \copy missing columns is a bug; we never had
it in previous release. Seems like a missing
Tom Lane wrote:
I was wondering whether an ALTER TABLE command is really the right way
to approach this. If we had an ALTER-type command, presumably the
implication is that its effects would be global to all backends. But
the uses that I've seen for suspending trigger invocations would be
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Well, I thought I did it, and it did work on my limited number of test
cases. Seems you got it fully working.
Actually, it failed for me (and evidently for Barry) on exactly the test
case you posted along with the patch. You said
Tom Lane wrote:
I was wondering whether an ALTER TABLE command is really the right way
to approach this. If we had an ALTER-type command, presumably the
implication is that its effects would be global to all backends. But
the uses that I've seen for suspending trigger invocations would be
Marc G. Fournier [EMAIL PROTECTED] writes:
On Mon, 14 Oct 2002, Tom Lane wrote:
I was wondering whether an ALTER TABLE command is really the right way
to approach this. If we had an ALTER-type command, presumably the
implication is that its effects would be global to all backends. But
the
OK, I would like to shoot for 7.3 final in the next few weeks. Can we
get some of these items completed so we can make that happen and move on
to 7.4? Remeber, PITR and Win32 are waiting!
Let me comment on these:
---
Denis A Ustimenko wrote:
On Sun, Oct 13, 2002 at 09:02:55PM -0700, Joe Conway wrote:
Denis A Ustimenko wrote:
Bruce, why have all precise time calculations been droped out in 1.206?
If there is no
gettimeofday in win32?
gettimeofday was not portable to win32 (at least not that I
Bruce Momjian wrote:
So, this is what needs to be dealt with to get it working.
More to the point, why is sub-second precision needed in this function?
Connection timeout is given to us in whole seconds (1.205 code, i.e. prior to
the patch in question):
remains.tv_sec =
Joe Conway wrote:
Bruce Momjian wrote:
So, this is what needs to be dealt with to get it working.
More to the point, why is sub-second precision needed in this function?
Connection timeout is given to us in whole seconds (1.205 code, i.e. prior to
the patch in question):
On Fri, Oct 11, 2002 at 08:30:55AM -0500, Greg Copeland wrote:
I'd be curious to hear in a little more detail what constitutes not
good for postgres on a mosix cluster.
It seems that almost all the postgres processes remain in the `home'
node.
Please notice that I am not underestimating
On Fri, Oct 11, 2002 at 07:10:26PM +0530, Shridhar Daithankar wrote:
On 11 Oct 2002 at 8:30, Greg Copeland wrote:
I'd be curious to hear in a little more detail what constitutes not
good for postgres on a mosix cluster.
Well, I guess in kind of replication we are talking here, the
On 14 Oct 2002 at 11:55, Anuradha Ratnaweera wrote:
On Fri, Oct 11, 2002 at 07:10:26PM +0530, Shridhar Daithankar wrote:
On 11 Oct 2002 at 8:30, Greg Copeland wrote:
I'd be curious to hear in a little more detail what constitutes not
good for postgres on a mosix cluster.
Well, I
On Fri, Oct 11, 2002 at 12:07:00PM -0400, Neil Conway wrote:
[ pgsql-patches removed from Cc: list ]
Anuradha Ratnaweera [EMAIL PROTECTED] writes:
I am trying to add some replication features to postgres (yes, I
have already looked at ongoing work), in a peer to peer manner.
Did you
Bruce Momjian wrote:
It could be argued that our seconds are not as exact as they could be
with subsecond timing. Not sure it is worth it, but I can see the
point.
Well, if we were specifying the timeout in microseconds instead of seconds, it
would make sense to have better resolution. But
Masaru Sugawara wrote:
I'm hoping that dblink_exec() returns something like warning if those who intend
to do transactions make a declaration of blink_exec('dbname=some', 'begin') by mistake.
for example
WARNING :You should declare dblink_exec('dbname=some', 'BEGIN; some queries;
I was spending some time investigating how to fix the jdbc driver to
deal with the autocommit functionality in 7.3. I am trying to come up
with a way of using 'set autocommit = on/off' as a way of implementing
the jdbc symantics for autocommit. The current code just inserts a
'begin' after
On Sat, 12 Oct 2002 23:37:18 -0700
Joe Conway [EMAIL PROTECTED] wrote:
Masaru Sugawara wrote:
I'm hoping that dblink_exec() returns something like warning if those
who intend to do transactions make a declaration of
blink_exec('dbname=some', 'begin') by mistake.
for example
Mike Mascari wrote:
How can dblink() possibly be used safely for non-readonly transactions
without a full implementation of a two-phase commit protocol? What
happens when the remote server issues the COMMIT and then the local
server crashes?
It can't be used safely if you're trying to ensure
Masaru Sugawara wrote:
Hi, all
While trying dblink_exec(), one of dblink()'s functions, I noticed there was an
odd situation: case 1 and case 2 worked well, but case 3 didn't(see below).
I hadn't been aware of it so that I only executed BEGIN and END in
dblink_exec() at first . This time,
36 matches
Mail list logo
