Skip site navigation (1) Skip section navigation (2)

Re: [GENERAL] Specific database vars, again...

From: Glus Xof <gtglus(at)gmail(dot)com>
To: Thomas Kellerer <spam_eater(at)gmx(dot)net>
Cc: pgsql-novice(at)postgresql(dot)org
Subject: Re: [GENERAL] Specific database vars, again...
Date: 2010-04-20 21:11:01
Message-ID: l2l18c2d6a11004201411g3d111b7dtddcf28b751341ddc@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-generalpgsql-novice
2010/4/20 Thomas Kellerer <spam_eater(at)gmx(dot)net>:
> Glus Xof wrote on 20.04.2010 21:35:
>>
>> The idea is storing values that can be remotely accessed by a
>> C++/libpqxx application. So, I just see that the first alternative
>> that I proposed (the use of \set variables) is really not good. But
>> the rest remains...
>>
>> Now, the only option I have is to create a table, define one column
>> per variable, for using just one row. This can be accessed by a select
>> sql command...
>>
>
> I don't understand why you need a column per variable.
>
> I'd use something like
>
> CREATE TABLE configuration_settings
> (
>   variable_name  text primary key not null,
>   variable_value text
> );
>
> INSERT INTO configuration_settings
> (variable_name, variable_value)
> VALUES
> ('myfirstvar', 'Some value');
>
> INSERT INTO configuration_settings
> (variable_name, variable_value)
> VALUES
> ('mysecondvar', 'Another value');
>

I can write it as you suggested.

Thanks a lot !,

Glus

In response to

pgsql-novice by date

Next:From: Adrian von BidderDate: 2010-04-21 08:11:48
Subject: Re: Specific database vars, again...
Previous:From: Thomas KellererDate: 2010-04-20 20:23:34
Subject: Re: [GENERAL] Specific database vars, again...

pgsql-general by date

Next:From: AndyDate: 2010-04-20 21:15:52
Subject: Performance impact of log streaming replication
Previous:From: mai fawzyDate: 2010-04-20 20:54:03
Subject: Rollback Failure

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group