variables for tables and columns?

Started by Kevalmost 18 years ago3 messages
#1Kev
kevinjamesfield@gmail.com

Would it be a lot of trouble to extend the ability that databases have
to store variables (add_missing_from, array_nulls, etc.) to tables and
columns, for use with user-defined variables?

This would make it cleaner, I think, to do things like automatically
build UIs for a table, using the variables to configure exceptions and
special features, especially when using mod_libpq or otherwise trying
to minimize the code that exists outside the database server.

What do you think?

Thanks,
Kev

#2Gregory Stark
stark@enterprisedb.com
In reply to: Kev (#1)
Re: variables for tables and columns?

"Kev" <kevinjamesfield@gmail.com> writes:

Would it be a lot of trouble to extend the ability that databases have
to store variables (add_missing_from, array_nulls, etc.) to tables and
columns, for use with user-defined variables?

Not following what you're trying to say at all. Perhaps an example of how what
you're thinking of would work would help?

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!

#3Kev
kevinjamesfield@gmail.com
In reply to: Kev (#1)
Re: variables for tables and columns?

On Apr 8, 10:40 am, st...@enterprisedb.com (Gregory Stark) wrote:

"Kev" <kevinjamesfi...@gmail.com> writes:

Would it be a lot of trouble to extend the ability that databases have
to store variables (add_missing_from, array_nulls, etc.) to tables and
columns, for use with user-defined variables?

Not following what you're trying to say at all. Perhaps an example of how what
you're thinking of would work would help?

Sorry, I mean whatever structure it is that lets you go into pgAdmin,
select a database, go to Properties, and hit the Variables tab. In
there you can set a bunch of per-database variables like
add_missing_from, search_path, etc.

I think these are just stored in pg_database.datconfig, no?

So what I would be proposing is adding that column to pg_attribute and
pg_class, I guess. But now that I put it that way it seems like that
would be a burden on some pretty key tables. Maybe it's not a very
good idea then.

Kev