[prev in list] [next in list] [prev in thread] [next in thread] 

List:       serdev
Subject:    [Serdev] postgres unstable crash - patch
From:       lgfausak () august ! net (Greg Fausak)
Date:       2004-04-27 10:53:02
Message-ID: m1BHvWi-002GL2C () gomer ! august ! net
[Download RAW message or body]

>
>On 25-04 18:08, Alexander Mayrhofer wrote:
>> On (25.04.04 17:24), Jan Janak wrote:
>> > > btw, are there any plans to make the "version" table name configurable?
>> > > It seems to be a compile time option now, but imho _all_ table names
>> > > should be configurable ...
>> >   
>> >   Well, I didn't plan to make it runtime-configurable. This table is
>> >   special because it contains the version of all other tables within the
>> >   database. All modules should use the same version table -- this is the
>> >   reason why it is not runtime-configurable.
>> > 
>> >   Do you need it configurable ?
>> 
>> Well:
>> 
>> 0(0) PG[238] db_init entry
>> 0(0) PG[362] submit_query query 'select version from version where
>>  table_name='subscriber_test'', result 'ERROR:  You can't use
>>  relation names alone in the target list, try relation.*.
>>  '
>>
>> The current default values don't even work with postgres. I strongly
>> suggest to at least rename the column "version" (It's already changed to
>> "table_version" in the ser_mysql.sh script, i'd be perfectly fine with
>> that). 
>
>  OK, I renamed the column to table_version so hopefully the conflict is
>  gone. It's interesting the the query above works in mysql.

Hmmm.... maybe it needs quoting or something:

myaugust=> select version from version where table_name = 'subscriber_test';
 version 
 ---------
 (0 rows)


>
>> You can argue about the "version" table, but i would love to see
>> it configurable.
>
>  To close on this, I would prefer to keep this as it is -- configurable
>  through config.h unless there is a really good reason to make it
>  runtime-configurable. The reason is that the table name should be same
>  in all modules and for that we would need a core parameter. Moreover
>  the table contains data about other tables and that's something users
>  should not mess with.
>
>     Jan.

I had a hard time in the beginning.  It seems like the table (and
especially column names) changed often.  This seems to have slowed down.

-greg


>
>_______________________________________________
>Serdev mailing list
>Serdev@iptel.org
>http://mail.iptel.org/mailman/listinfo/serdev
>

[prev in list] [next in list] [prev in thread] [next in thread]