Monday, October 26. 2009Lowercasing table and column namesPrinter FriendlyComments
Display comments as
(Linear | Threaded)
Wouldn't what's below, which is your code with the array_to_string(array())
peeled off, Just Work(TM)? SELECT 'ALTER TABLE ' || quote_ident(c.table_schema) || '.' || quote_ident(c.table_name) || ' RENAME "' || c.column_name || '" TO ' || quote_ident(lower(c.column_name)) || ';' FROM information_schema.columns As c WHERE c.table_schema NOT IN('information_schema', 'pg_catalog') AND c.column_name lower(c.column_name) ORDER BY c.table_schema, c.table_name, c.column_name; Anyhow, one trick I've used when using SQL to generate SQL is to do it in psql. * Invoke psql with -At (noalign, tuples only), or set same during the session. * Check that the output looks right. What's below can shoot your whole leg off, not just put holes in your foot. * \o |psql myuser mydb * \g * \o Cheers, David.
David,
I've been contemplating writing it the way you have it just so its easier to read. That works fine if you are working in psql, but most of the time we are working in PgAdmin III and so do most of our customers. So the problem is that that approach gives you a record for each statement so when you copy and paste it into the query window it has all these annoying quotes around it that you then have to macro replace out. Thanks, Regina
I hadn't known about the requirement that this be done through pgAdminIII, which seems like a bizarre requirement at first blush. Anyhow, \r is a Windows-only thing which pretty well breaks on other platforms. It also doesn't quite handle best practices, which would be putting all DDL in your source code management system.
It seems to me that piling a kludge on top of the fact that you're using an unsuitable tool (pgAdminIII) for the job is a great way to waste a lot of time and effort where simply choosing a more appropriate tool is a much better way to approach things. Of course, if yet another unstated requirement is to make the system obscure by creating secret knowledge, which in turn bumps up the hours you'll be charging to deal with it, your idea makes a large amount of sense.
David,
I take it I must have offended you with my windows/PgAdmin III centric lifestyle to deserve such a backlash or you are just a person who likes to start debates. I have taken your advice and included the single row ddl way, but I still prefer my way better for my general usage. Now getting back to your comment about bashing my favorite tool of choice and how I treat "my customers". For most day to day use I prefer PgAdminIII (not everything) I like psql for a lot of things like automated testing and so forth. This is not necessarily one I feel one tool is greatly stronger than another. We can't all be power psql users like you and not all people want to source control everything in their life. I have come to accept the proposition that the factors that determine the best tool for the job are the job, the person doing it, and the current mood of that person. If I want my customers to be self-reliant, I need to let them use tools they feel most comfortable with -- e.g. ArcGIS this, Safe ETL that, and PgAdmin III whether or not I prefer those tools myself and to some extent, that does mean I do need to understand them, and work around their short-comings etc. Trust me I have tried to get customers introduced to psql -- and often I get "Where are the lights?" As Leo likes to say when he bought his first stick shift car "I buy a stick-shift because I feel more in control with it, its $2000 cheaper, and I know that since most of my friends can't drive stick, they won't ask to play with my toy. Sometimes when I'm sitting on a long drive with lots of stops -- I really don't care to think that hard, I just want an automatic." So to me psql is a stick -- sure you can do a lot of things with it you can't with PgAdmin III, but with PgAdminIII -- I click a bunch of fairly intuitive buttons look at the sql it generates if I care, and go on with my business. My customers don't care about learning the ins and outs of how to write ddl statements, they just want to create their damn tables and foreign keys and what not.
Regina,
You seem to be under the misapprehension that I dislike pgAdminIII and/or Windows. While I seldom use either of those tools, nothing could be further from the truth. What you left out of your original article was that the procedure added code which specifically ties it to both. I understand that sometimes we forget to put in "the obvious," but in this case, you: * Obfuscated the code, and in the process * Broke how this would work in any toolchain other the two pieces of software you had in mind. You stated no reason, and this puzzled at least me, and very likely others. To put it at its most generous, which I'm inclined to do, your code looks a lot like an entry for an obfuscated coding contest. If that is what it is, please do the rest of us the courtesy of so labeling it next time. P.S. Please let people format code using "pre" (or other--Serendipity has lots of options) tags so our code doesn't flatten into illegibility when we post it.
David,
My point is I'm not going to jump into PSQL for something as trivial as this just because PSQL might be a slightly better tool for this. Ruins my train of thought is all constantly jumping from editing tool to editing tool. But you are correct -- I was oblivious to the fact that this may not behave as nicely in PSQL and other tools people commonly use for this. So thanks for that observation. Hmm the code looks okay to me in my IE and Firefox browser. Which browser are you looking at? This is the first time I'm hearing its illegible. Now the reason I don't use Serendipity for my code formatting is as you may say another "obvious to me but not to you", thing and that is because I don't display the content just in serendipity. I need to flip it into a PDF among other formats and I'm very particular about how that is done. |
Entry's LinksQuicksearchCalendar
Categories
Blog Administration |
Tracked: Jan 28, 11:22
Tracked: Jun 14, 13:46
Tracked: Jan 27, 02:01