Hello everyone,
I'm building a postgresql db which will have to get lots of data
from the outside (customers, that is). The db has lots of
constraints, and I'm sure that our customers will offer lots of
invalid information. We receive the information in csv format. My
first thought was to read
Mike Rylander zei:
On Fri, 4 Feb 2005 13:32:40 +0100 (CET), Joolz
[EMAIL PROTECTED] wrote:
Hello everyone,
I'm building a postgresql db which will have to get lots of data
from the outside (customers, that is). The db has lots of
constraints, and I'm sure that our customers will offer lots
Michael Glaesemann zei:
On Feb 4, 2005, at 21:32, Joolz wrote:
What I need is an import where all valid lines from the csv files
are read into the db, and I also get a logfile for all invalid
lines, stating the line number plus the pg error message so I can
see which constraint was violated
Csaba Nagy zei:
[snip]
I'm afraid this is a bit too indirect IMHO. As I want to know the
line number in which an error occurs, I would have to traverse the
error-tolerant table with limit 1 offset N, and report N when an
error occurs, hoping that the row order is identical to the line
order
Sean Davis zei:
I use a trigger on tables with foreign key references to either
ignore
the insert row or insert an appropriate matching row in the
referenced
table, if it does not exist. In the function, I just raise a notice
that I am doing this. This is a simple example:
create or
Hello everyone,
When writing some serverside code I ran into an oddity that I
managed to boil down to this:
---
create or replace function fubar() returns varchar as '
declare
l integer;
begin
l = 38;
if l 38 then
return '' 38'';
Ian Barwick zei:
On Thu, 16 Dec 2004 10:06:19 +0100 (CET), Joolz
[EMAIL PROTECTED] wrote:
Hello everyone,
When writing some serverside code I ran into an oddity that I
managed to boil down to this:
---
create or replace function fubar
Richard Huxton zei:
Hi Richard,
See the other posting,
elseif l = 38
Apparently this is parsed as
elseif l = 38
^ ^
| |
code|
|
comment from here on
It should be elsif, not elseif :-\
Thanks everyone!
---(end of
Tomasz Myrta zei:
When writing some serverside code I ran into an oddity that I
managed to boil down to this:
---
create or replace function fubar() returns varchar as '
declare
l integer;
begin
l = 38;
if l 38 then
return
Hello everyone,
When I create a table and later on (say, because customers want to
store extra info) add a column, like this:
create table test (lastfield varchar);
alter table test add column firstfield varchar;
is it possible to change the natural order of the columns
afterwards? The
Tino Wildenhain zei:
Hi,
Am Dienstag, den 30.11.2004, 10:26 +0100 schrieb Joolz:
Hello everyone,
When I create a table and later on (say, because customers want to
store extra info) add a column, like this:
create table test (lastfield varchar);
alter table test add column firstfield
Richard Huxton zei:
Joolz wrote:
I dont think the overhead in implementing such a rarely needed
feature isnt worth it. We need a lot more other things ;-)
I agree. Only I think this wouldn't require new functionality, I
have a gut feeling that this is possible as it is. Now only find
out
Daniel Martini zei:
Hi,
Joolz, you already got quite a few answers, that the frontend is
probably
not properly designed, if it relies on a certain column ordering. I
agree
Hi Daniel,
Well, I made the frontend myself, so... :)
There is a reason that I made it this way, I have a database
Michael Glaesemann zei:
OIDS are a system level implementation. They are no longer required
(you can make tables without OIDS) and they may go away someday.
Out of curiosiry: how will we handle blobs once the OID's are gone?
---(end of
SUCK MY WHITE COCK!
SWALLOW MY FUCKING CUM!
LICK AROUND THE CRACK OF MY ASSHOLE!
LICK MY FORESKIN CHEESE!
BLACK NIGGERS EAT WATERMELON!
Joolz
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
LICK MY BALLS and ASSHOLE and COCK
Mike Cox
Joolz
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
SWALLOW CUM from my COCK HOLE
Mike Cox
Joolz
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
FUCK YOUR MOTHERS CUNT
Mike Cox
Joolz
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
CUM ON MY ASSHOLE
Mike Cox
Joolz
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
FUCK MY WIFES CUNT and TITS
Mike Cox
Joolz
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
TIT-FUCK my wife's CUNT and ASSHOLE
Mike Cox
Joolz
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
BLACK NIGGERS are SPOOKS and JIGGABOOS
Mike Cox
Joolz
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message
NIGGERS SUCK COCK and SWALLOW CUM LOADS
Mike Cox
Joolz
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message
AFRICAN NIGGERS FUCK CUNTS
Mike Cox
Joolz
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Peter Eisentraut zei:
Am Dienstag, 16. November 2004 10:01 schrieb Joolz:
Michael Glaesemann zei:
OIDS are a system level implementation. They are no longer
required
(you can make tables without OIDS) and they may go away someday.
Out of curiosiry: how will we handle blobs once the OID's
Hi everyone,
When importing a bunch of data ( 85000 rows) I get an error I can't
explain. The table into which I'm importing has a unique clause on
(code, bedrijf). The rows in the source-table are unique in this
aspect, yet when I do the import I get this ERROR: duplicate key
violates unique
Tom Lane zei:
Joolz [EMAIL PROTECTED] writes:
Is there a bug in the UNIQUE behaviour?
No known bugs, anyway. I'm inclined to guess that your target table
has
slightly different datatypes than the source, and that results in
equal
values for some reason (such as fractional values being
Hello everyone,
Sorry if this is a FAQ, but I've groups.googled the subject and
can't find a definite answer (if such a thing exists). I'm working
on a db in postgresql on a debian stable server, ext3 filesystem.
The db will contain files, not too many (I expect somewehere between
10 and 100
[Stephan Szabo schreef op 16-06-2004 07:57 -0700]
On Wed, 16 Jun 2004, Joolz wrote:
In my db I have a table type_of_action, fields code varchar, name
varchar, medical boolean. Two other tables refer to this table,
one of them to the medical rows, the other one to the none-medical
rows
29 matches
Mail list logo
