I usually write about PostgreSQL, but lately someone asked for help, and one of the problems was similar to sudo command from title.
This was not the first time I saw it, so figured, I'll write a blogpost about it, just so I can refer people to it in the future.
On 8th of November, Tom Lane committed patch, which doesn't provide any new features, but removes one of the more annoying footguns in PostgreSQL:
Prevent invoking I/O conversion casts via functional/attribute notation. PG 8.4 added a built-in feature for casting pretty much any data type to string types (text, varchar, etc). We allowed this to work in any of the historically-allowed syntaxes: CAST(x AS text), x::text, text(x), or x.text. However, multiple complaints have shown that it's too easy to invoke such casts unintentionally in the latter two styles, particularly field selection. To cure the problem with the narrowest possible change of behavior, disallow use of I/O conversion casts from composite types to string types via functional/attribute syntax. The new functionality is still available via cast syntax. In passing, document the equivalence of functional and attribute syntax in a more visible place.
I had today a very weird situation.
From my laptop, I ssh to another system, and from there to yet another.
On this final system I noticed that vim starts relatively slow. i.e. this command:
time vim -u /dev/null -c “:q"
returned time in around 3.5 seconds, while on my laptop (which is much less powerful) it is:
=> time vim -u /dev/null -c ":q" real 0m0.073s user 0m0.056s sys 0m0.016s
I tried to debug the situation, and it got weirder. If I did “su – another_user" (on the final system) – it became fast. What's more: if I did su – depesz (my account) back – vim was still fast!
After some debugging it occurred to me: I have automatic X11 forwarding turned on. I checked – and yes, in the shell that vim starts slowly, i had “DISPLAY" variable, set to localhost:10.0!
Quick unset DISPLAY, and suddenly vim starts 0.027s!
Lesson for future – do not use automatic X11 forwarding for long-distance ssh connections, or make sure you run vim with “-X" option.
Later I learned why it tries X11 connection – to get access to X copy/paste buffer (available as * register). Nice feature, but with quite problematic side effects.
I was lately writing some program for a client of mine, which used UPC codes matching.
Since the codes are given in various ways, there was decision to pad the codes with leading zeros – up to 12 characters.
The code has been done, and worked like this:
# SELECT lpad('123456789', 12, '0'); lpad -------------- 000123456789 (1 ROW)