Thread: variables for tables and columns?

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

"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!

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