From: | Ben Chobot <bench(at)silentmedia(dot)com> |
---|---|
To: | Glus Xof <gtglus(at)gmail(dot)com> |
Cc: | pgsql-novice(at)postgresql(dot)org |
Subject: | Re: [GENERAL] Specific database vars, again... |
Date: | 2010-04-20 19:38:15 |
Message-ID: | 29BD5FD6-5485-465B-962C-0073D8763178@silentmedia.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-novice |
On Apr 20, 2010, at 12:35 PM, Glus Xof wrote:
> 2010/4/20 Ben Chobot <bench(at)silentmedia(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Glus Xof | 2010-04-20 20:08:03 | Re: [GENERAL] Specific database vars, again... |
Previous Message | Glus Xof | 2010-04-20 19:35:16 | Re: [GENERAL] Specific database vars, again... |
From | Date | Subject | |
---|---|---|---|
Next Message | Glus Xof | 2010-04-20 20:08:03 | Re: [GENERAL] Specific database vars, again... |
Previous Message | Glus Xof | 2010-04-20 19:35:16 | Re: [GENERAL] Specific database vars, again... |