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. O
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 n
> > "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 her
> 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, di
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 - H
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 th
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
> -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)
>
>
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 pr
10 matches
Mail list logo
