Horton

Thread

  1. Specific database vars, again...

    Glus Xof <gtglus@gmail.com> — 2010-04-20T17:53:34Z

    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

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

    Ben Chobot <bench@silentmedia.com> — 2010-04-20T19:16:31Z

    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?

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

    Glus Xof <gtglus@gmail.com> — 2010-04-20T19:35:16Z

    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

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

    Ben Chobot <bench@silentmedia.com> — 2010-04-20T19:38:15Z

    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.

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

    Glus Xof <gtglus@gmail.com> — 2010-04-20T20:08:03Z

    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

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

    Thomas Kellerer <spam_eater@gmx.net> — 2010-04-20T20:23:34Z

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

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

    Glus Xof <gtglus@gmail.com> — 2010-04-20T21:11:01Z

    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

  8. Re: Specific database vars, again...

    Adrian von Bidder <avbidder@fortytwo.ch> — 2010-04-21T08:11:48Z

    On Tuesday 20 April 2010 19.53:34 Glus Xof wrote:
> Could I use the \set statements

\set is a feature of the "psql" commandline frontend.  These values are 
never even seen by the database and are not preserved anywhere.  Also, if 
you develop applications, you'll usually not use the psql frontend but use 
PostgreSQL through some other interface (libpq, Perl DBD, JDBC, ...), so 
there won't be a "\set" command.

cheers
-- vbi

-- 
If you continually give you will continually have.

  9. Re: [NOVICE] Specific database vars, again...

    Rene Schickbauer <rene.schickbauer@gmail.com> — 2010-04-21T08:14:02Z

    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

  10. Re: Specific database vars, again...

    Glus Xof <gtglus@gmail.com> — 2010-04-22T13:07:21Z

    Thanks to all that replied my question !

I'll implement the Thomas Kellerer's.

Glus