Nicolas Grilly ngrilly

## bug_pg_copy_from.py
"""
It looks like copy_from does not stop reading after an error. When the input file is short,
it is okay. But when the input file is very long, it is really boring to wait for the entire file
to be read just to discover there is an error on the 10th row.

Given the same input file, it looks like psql \copy command behaves correctly and stops
just after the incorrect row, without reading the entire file. I have checked that just by looking
at the command execution time that seems proportional to the number of processed rows...

Here is a script to reproduce this bug (just create a database "test" and run the script).

## auth.go
package auth

import (
	"net/http"
	"net/url"
	"strings"
	"time"

	"lib/crypto"
	"lib/utils"

## collision_probability.py
"""
ULID probability of collision
"""

import decimal

# A ULID uses 80 bits of entropy
d = decimal.Decimal(2**80)

# Generate 1,000 ULIDs per millisecond (1,000,000 per second)
	"""
	It looks like copy_from does not stop reading after an error. When the input file is short,
	it is okay. But when the input file is very long, it is really boring to wait for the entire file
	to be read just to discover there is an error on the 10th row.

	Given the same input file, it looks like psql \copy command behaves correctly and stops
	just after the incorrect row, without reading the entire file. I have checked that just by looking
	at the command execution time that seems proportional to the number of processed rows...

	Here is a script to reproduce this bug (just create a database "test" and run the script).
	package auth

	import (
	"net/http"
	"net/url"
	"strings"
	"time"

	"lib/crypto"
	"lib/utils"
	"""
	ULID probability of collision
	"""

	import decimal

	# A ULID uses 80 bits of entropy
	d = decimal.Decimal(2**80)

	# Generate 1,000 ULIDs per millisecond (1,000,000 per second)