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
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 lin
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
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
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 t
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 broadcast)
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 <
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:
>>
>>
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'';
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
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
>>
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 (
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 reaso
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.
>>
>&g
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
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
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
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])
FUCK MY WIFES CUNT and TITS
Mike Cox
Joolz
[EMAIL PROTECTED]
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go 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 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])
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
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])
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
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 broadcast)
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
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 co
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 files
> [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 r
29 matches
Mail list logo
