"Andreas Pflug" <pgadmin@pse-consulting.de> writes:
> Gregory Stark wrote:
>> "Andreas Pflug" <pgadmin@pse-consulting.de> writes:
>>
>>> Why do so many people here insist on editing postgresql.conf as primary means
>>> of changing config params?
>>> Isn't a psql -c "SET foo=bar; MAKE PERSISTENT" just as good as sed'ing
>>> postgresql.conf or doing it manually?
>>
>> no, it's awful.
>
> So I wonder why you accept it when configuring schemas. What's the big
> difference between setting a config param, and creating a table?
Yes, this is a big impedence mismatch between the old-school DBMS (with
emphasis on the MS part of the acronym) architecture and more modern
approaches. You don't configure your web site with "ALTER PAGE home.html SET
FORM contactus INPUT TYPE SUBMIT" either...
This is partly out of necessity though as those database objects contain
*data*. So merely replacing them with new data objects doesn't give the system
enough information to understand what to do with that data. The DDL commands
which modify the schema give that kind of data mutating instruction.
And I'll note that DBAs go to *great* lengths to do exactly the same kind of
thing I described the CISCO DBAs doing. Usually that means doing an ALTER
command and separately editing a creation script and trying to keep the two in
sync. It's a huge burden.
> And ultimately, the config param file format may well look like an SQL command
> file, restricted to SET only.
So all you have is our existing file except with an additional layer of
quoting to deal with, a useless SET keyword to annoy users, and a file that
you need a bison parser to deal instead of a simple keyword-value syntax that
sed can manipulate.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support!
