Specific database vars, again...

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?

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

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.

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

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.

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