Christopher Kings-Lynne wrote:
It's more likely that your changes will go through if you just submit a
patch!
I suggested to discuss it first, since it's IMHO more likely
that the changes go through if they are commonly accepted in
the first place.
Jan
cvs diff -c
Chris
2. Add _P to the following lex/yacc tokens to avoid collisions
CONST, CHAR, DELETE, FLOAT, GROUP, IN, OUT
I'm tempted to suggest that we should stick _P on *all* the lexer token
symbols, rather than having an inconsistent set of names where some of
them have _P and some do not. Or
Thomas Lockhart [EMAIL PROTECTED] writes:
I'm tempted to suggest that we should stick _P on *all* the lexer token
symbols, rather than having an inconsistent set of names where some of
them have _P and some do not. Or perhaps _T (for token) would be a more
sensible convention; I'm not sure
P for Parser.
Oh, okay. I'm not intent on changing it, just was wondering what the
motivation was. What do you think of changing all the token symbols to
be FOO_P? (Or P_FOO, per your comment, but I'd just as soon leave alone
the ones that already have a suffix.)
No problem here. I have
Christopher Kings-Lynne wrote:
It's more likely that your changes will go through if you just submit a
patch!
I suggested to discuss it first, since it's IMHO more likely
that the changes go through if they are commonly accepted in
the first place.
Yep - sorry, didn't
Thomas Lockhart [EMAIL PROTECTED] writes:
Question to all: Any objection to postfix? If so, why?
Well, I suggested DTF_FOO by analogy to the DTK_FOO name set that appears
elsewhere in that same header. If you want to rename those to FOO_DTK
in parallel, I have no objection.
IGNORE_TOK - How
I'm trying to determine if database growth (with LO) that I'm seeing during
a pg_restore is fixed by the patch identified at
http://archives.postgresql.org/pgsql-hackers/2002-04/msg00496.php , but when
I attempt to restore from a 7.2.1 created dump into my newly created
7.3devel database, I get
Ron Snyder [EMAIL PROTECTED] writes:
I attempt to restore from a 7.2.1 created dump into my newly created
7.3devel database, I get this:
pg_restore: [archiver (db)] could not create large object cross-reference
table:
I didn't find any mention of this on the hackers mail archive, so I
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 31, 2002 3:24 PM
To: Ron Snyder
Cc: pgsql-hackers
Subject: Re: [HACKERS] Can't import large objects in most
recent cvs (20020531 -- approx 1pm PDT)
Ron Snyder [EMAIL PROTECTED] writes:
I
Argh. I just realized that I gave this the wrong subject-- it should've been
Can't pg_restore large objects
Digging a bit, I've discovered this:
1) usesysid 1 owns the database in the old server, but all
the tables are
owned by 'qvowner' (and others).
2) qvowner does not have dba privs
10 matches
Mail list logo
