Thread: Specific database vars, again...

Hi again,

Maybe, I didn't explain my question enough.

I need to record properties that belongs to an specific database (and
so, they work at database level... not at global scope:

* Could I use the \set statements ? but... the vars defined are not in
a database scope but a global, aren't they ?... furthermore, could
save these vars when try to dump the database ??? )

* Or, must to create an specific one-row table ?.

Glus

2010/4/20 Ben Chobot <bench@silentmedia.com>:
>
> On Apr 20, 2010, at 10:53 AM, Glus Xof wrote:
>
>> Hi again,
>>
>> Maybe, I didn't explain my question enough.
>>
>> I need to record properties that belongs to an specific database (and
>> so, they work at database level... not at global scope:
>>
>> * Or, must to create an specific one-row table ?.
>
> Depending on how you intend to use these variables, this sounds like a fine idea to me. What are your problems with
it?

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...

You know other alternatives ???

Glus

2010/4/20 Ben Chobot <bench@silentmedia.com>:
> On Apr 20, 2010, at 12:35 PM, Glus Xof wrote:
>
> 2010/4/20 Ben Chobot <bench@silentmedia.com>:
>
> On Apr 20, 2010, at 10:53 AM, Glus Xof wrote:
>
> Hi again,
>
> Maybe, I didn't explain my question enough.
>
> I need to record properties that belongs to an specific database (and
>
> so, they work at database level... not at global scope:
>
> * Or, must to create an specific one-row table ?.
>
> Depending on how you intend to use these variables, this sounds like a fine
> idea to me. What are your problems with it?
>
> 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...
>
> You know other alternatives ???
>
> I could probably think of some, but why? Storing values in tables is a
> perfectly sensible way to allow clients to access per-database data.

Thanks !

Glus

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');

2010/4/20 Thomas Kellerer <spam_eater@gmx.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

Glus Xof wrote:
> Hi again,
>
> Maybe, I didn't explain my question enough.
>
> I need to record properties that belongs to an specific database (and
> so, they work at database level... not at global scope:
>
> * Could I use the \set statements ? but... the vars defined are not in
> a database scope but a global, aren't they ?... furthermore, could
> save these vars when try to dump the database ??? )
>
> * Or, must to create an specific one-row table ?.

The first things to ask is: Do multiple transactions change this data?
What is something goes wrong - do you need rollback to work?

Anyway, a table with one or only a few rows is very likely to be cached
in RAM by postgres anyway if you access it regulary. So performance
shouldn't be an issue.

LG
Rene

Thanks to all that replied my question !

I'll implement the Thomas Kellerer's.

Glus

On Apr 20, 2010, at 10:53 AM, Glus Xof wrote:

> Hi again,
>
> Maybe, I didn't explain my question enough.
>
> I need to record properties that belongs to an specific database (and
> so, they work at database level... not at global scope:
>
> * Or, must to create an specific one-row table ?.


Depending on how you intend to use these variables, this sounds like a fine idea to me. What are your problems with it?