But that's because IBM has a strong presence in the SQL standard committee and can nudge it to standarise (post-factum) things they already implemented in DB2.
HN user
wulczer
Engineer at New Relic (personal email: wulczer-hn@wulczer.org)
[ my public key: https://keybase.io/wulczer; my proof: https://keybase.io/wulczer/sigs/g46dYvOOsEpYFfTEQUY4Hwj5x_gO3JSvfDNXnd4pjvI ]
Since all of the previous states are there in the repo history, you can make that gif yourself at any moment!
Postgres at least will store rows roughly in insert order. So whether you're using integers or UUIDs for primary keys won't affect on-disk layout.
When scanning the index, the database will be traversing it in btree order, anyway, so as long as the values are comparable, ints or UUIDs shouldn't matter much.
Sorry, ticked off my OCD :)
It's better to say "key text" instead of "key varchar(1024)" and primary key already implies not null.
Thanks!
We're staying in Spain and there are plans to further grow the Barcelona office.
Obligatory Show HN where we first showed Ducksboard to the world (1301 days ago): https://news.ycombinator.com/item?id=2332464
Thanks for all the feedback and interest we got from the community through all those years and just because we now work at New Relic doesn't mean we'll stop procrastinating on HN!
What is the epiphany here? What is the insight or enlightenment to be gained from this story?
I have my own, but I'm curious about what people believe is the moral of the story.
That's also why, when you go to the movies and it turns out tickets cost the same regardless of the film, you should go for the one with the longest running time.
One of the important reasons Postgres connections are serviced by a separate process is that if that process segfaults, you only disconnect other connections (because if might have tainted shared memory when it died), but the main database process keeps running and you can reconnect immediately.
Almost two years ago the "The Pulse of Spain" was made, based on the same idea (disclaimer: the designers of this are also designers for our product (and dear friends)).
It's in Spanish, unfortunately. You have to click on the tiles to activate them and they'll start pulsating. If you have Flash, there'll be sound.
The link is:
Since everyone is plugging their own: here's a identity provider daemon written in Go:
https://github.com/wulczer/persona-idp
It uses my Mail Transfer Agent to identify, so I can just use me email password to log in to Persona-enabled sites, but you can easily swap it out for a different credentials checker.
Logs subpoenaed from your ISP show that you were using Tor between 3:10 and 5:23 PM on 02/05/2012.
Logs from forensic analysis of a breakin to EvilCorp show that the attacker came in from Tor and was downloading secret data from 3:10 to 5:23 PM on the same day.
Not enough to prove anything, but there's definitely some circumstantial evidence there.
Why can't you use a connection that has issued LISTEN for anything else? In fact, I'm fairly sure you can use it normally.
We're using NOTIFY to broadcast database changes to services that should react to them and it's quite a nice way to separate concerns: process A just writes to the database, a trigger issues a NOTIFY, process B checks and notices there's been a change.
Edit: I see, the code in the post suggests that the connection needs to be stuck in a select() (I should know, I contributed a largre chunk of psycopg2's async code handling). You just need to use an asynchronous driver and you can happily LISTEN and do queries at the same time (of course you won't get notifies while a query is processing - the Postgres protocol has no concept of multiplexing).
We're using Twisted and happily mixing queries and NOTIFY.
Reminds me of http://www.supersimplestorageservice.com/
BTW, I think at least in Peninsular Spanish you'd say "Viva Brasil" (omitting the article).
We wrote a similar utility for our ORM-for-SaaS library some time ago, using lxml if available and falling back to ElementTree:
https://github.com/ducksboard/libsaas/blob/master/libsaas/xm...
Bear in mind that both approaches are lossy - trying to support every XML quirk would quickly lead to reimplementing the libxml wheel...
Not really, the ones calling down to date_trunc should be marked as STABLE, since the underlying function is STABLE.
psql=$ \df+ date_trunc
Schema | Name | Result data type | Argument data types | Type | Volatility | Owner | Language | Source code | Description
------------+------------+-----------------------------+-----------------------------------+--------+------------+----------+----------+-------------------+------------------------------------------------------
pg_catalog | date_trunc | interval | text, interval | normal | immutable | postgres | internal | interval_trunc | truncate interval to specified units
pg_catalog | date_trunc | timestamp without time zone | text, timestamp without time zone | normal | immutable | postgres | internal | timestamp_trunc | truncate timestamp to specified units
pg_catalog | date_trunc | timestamp with time zone | text, timestamp with time zone | normal | stable | postgres | internal | timestamptz_trunc | truncate timestamp with time zone to specified unitsI've been thinking about switching to sup a few times, but the inability to sync changes back to the IMAP server is a deal breaker to me.
If I mark an email as read in sup, I don't want it to show up as unread on my phone. If I delete an email on the phone, I don't want it to stay in sup.
I know there's been a branch of sup that synced IMAP flags from the local repo to the server, solving at least the read status problem. But it seems the version linked here does not include that branch.
We have one on https://demo.ducksboard.com/ too :)
Doesn't matter if it's MD5 or SHA512. You can extend either hash function in the exact same way (http://en.wikipedia.org/wiki/Length_extension_attack)
it does when using the re.U flag
re.match(r'\d', u'੧', re.U)
<_sre.SRE_Match at 0x3070ac0>
sys.version
2.7.3 (default, Mar 4 2013, 14:57:34) \n[GCC 4.7.2]What I meant is that using PKCS#5 padding ("N bytes of a value of N") will make it even more susceptible to a CBC oracle attack.
I'm not nearly qualified to talk about that stuff, but instead of requiring PyCrypto maybe you should require Keyczar (http://code.google.com/p/keyczar/) and not have to worry about padding, IVs etc
Once this TODO is completed and real PKCS#5 is used, CBC padding oracle attack?
https://github.com/mothran/bunny/blob/master/libbunny/AEScry...
I thought most disks nowadays support Secure Erase, so there's no need to futz around with dd.
Seems so, the code in question appears to have been added here:
https://github.com/git-mirror/nginx/commit/7c7ad803a13d5f73b...
Create a new GitHub account, give it write access to the repo, generate a fresh RSA keypair, post the private key.
Check out http://www.gnu.org/software/stow/
Better idea: check which of those keys are in the Debian Weak SSH Keys list and own their GitHub accounts (or find if they have any servers and start SSHing into them).
Less nefariously: send them an email asking to regenerate the key.
Yes, thank you, sorry for too big of a mental shortcut.
By bad tests I mean trivial tests (much like trivial comments that just state the obvious), or ones that work on an assumption that need not be generally true and thus changes of the code that are correct from a logic standpoint might still make them fail.