Hi
What is wrong?
$result = pg_Exec($db,"COPY forum FROM {'datei.csv' | stdin} USING
DELIMITERS '|';");
I will load datei.csv into forum!
This is for MySQL:
$result = pg_Exec($db,"LOAD DATA INFILE 'datei.csv' INTO TABLE forum FIELDS
TERMINATED BY '|' LINES TERMINATED BY '\n'");
And for Postg
Here's some more details:
The following query:
SELECT * FROM tblpemdruglink WHERE drugid = 'DG-5039';
returns the following results:
drugid | monographid
-+-
DG-5039 | 2008
(1 row)
the following query:
SELECT * FROM tblfdbmono WHERE
monographid='2008' AND
versionid
David,
About the case-sensitivity, I was under the impression that PostgreSQL
was case-insensitive unless things were explicitly put in quotes. This
is at least what I read in the book ...
-Brice
David Olbersen wrote:
>
> On Thu, 1 Feb 2001, Brice Ruth wrote:
>
> ->SELECT
> -> a.Number,
> -
Hi,
This is my first experinece in writing to u. Please excuse any obvious errors.
I have only recently started using the postgres database and i would like to know if
it is possible to return a record from the fucntion(both sql and plpgsql).
I tried this code.. but the reuslt i got was
creat
Is it possible to know why datetime datatype does not accept null value? It
does at the beginning but if I enter a value and then decide to leave it
blank it won't accept "WHY"?
PLEASE if you can help write me back...
THANK YOU
> > Has been removed from the LDP website.
>
>>Good news indeed!
>>
>>Now what are we going to do with it?
>>
>>Can the original document's source be made available so that
>>somebody can do the needed work without having to re-key.
>>
>>There is a _lot_ of very good information in there buried u
> Has been removed from the LDP website.
>Good news indeed!
>
>Now what are we going to do with it?
>
>Can the original document's source be made available so that
>somebody can do the needed work without having to re-key.
>
>There is a _lot_ of very good information in there buried underneath t
the LDP project doesn't allow for 'taking over' someone elses work, but
Thomas is working the sites maintainer on an appropriate solution for the
problem, as even though its removed, it will come back again *groan*
On Tue, 6 Feb 2001, Thomas Swan wrote:
> > Has been removed from the LDP websit
Brice Ruth <[EMAIL PROTECTED]> writes:
> About the case-sensitivity, I was under the impression that PostgreSQL
> was case-insensitive unless things were explicitly put in quotes.
Names in queries (of tables, fields, functions, etc) are
case-insensitive. This has nothing to do with the behavior
That was my understanding as well, thank you for the clarification. :)
Tom Lane wrote:
>
> Brice Ruth <[EMAIL PROTECTED]> writes:
> > About the case-sensitivity, I was under the impression that PostgreSQL
> > was case-insensitive unless things were explicitly put in quotes.
>
> Names in queries
Hi
try
COPY forum FROM 'datei.csv' USING DELIMITERS '|';
You should use either 'filename' OR stdin, not both.
Hope it helps.
Regards,
Patrik Kudo
--
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
Känns det oklart? Fråga på!
On Tue, 6 Feb 2001, Sebastian wrote:
> Hi
>
>
Patrik Kudo <[EMAIL PROTECTED]> writes:
> COPY forum FROM 'datei.csv' USING DELIMITERS '|';
> You should use either 'filename' OR stdin, not both.
Check. You'll probably also find that you need to supply an absolute
pathname, since the backend is not running in the same directory that
your clien
Technically you are not allowed to make an FK to non-unique
values. What you're closer to looking for is MATCH PARTIAL
which we don't support (because it's a real pain - although
with the new memory management stuff in 7.1 it may be less
of one - since the fundamental problem is storing values
f
My script is below.
I thought (based on recent posts) that this use of RETURN is allowed, but
when trying an insert to report_table, I get the following error:
ERROR: control reaches end of trigger procedure without RETURN
I have solved several problems in getting to this point, but have now r
Jeff Eckermann <[EMAIL PROTECTED]> writes:
> I thought (based on recent posts) that this use of RETURN is allowed, but
> when trying an insert to report_table, I get the following error:
> ERROR: control reaches end of trigger procedure without RETURN
Looks to me like you didn't cover the case w
Folks,
Where do I send bug reports for 7.1 beta? I;'ve looked on the web
site, and don't see an address or bugtraq forum.
-Josh Berkus
--
__AGLIO DATABASE SOLUTIONS___
Josh Berku
I'll be hornswoggled: that works.
I hadn't expected a problem, simply because I knew the range in advance:
here is the distribution for the select that I was working with:
extracts=# select billing_frequency, count (*) from report_table group by
billing_frequency;
billing_frequency | count
-
Jeff Eckermann <[EMAIL PROTECTED]> writes:
> I'll be hornswoggled: that works.
> I hadn't expected a problem, simply because I knew the range in advance:
Odd. Maybe there is a compile-time, rather than run-time, check in
plpgsql for falling off the end without a RETURN? I haven't looked ...
On Wed, 7 Feb 2001, Josh Berkus wrote:
> Folks,
>
> Where do I send bug reports for 7.1 beta? I;'ve looked on the web
> site, and don't see an address or bugtraq forum.
Probably the best is the pgsql-bugs mailing list at:
[EMAIL PROTECTED]
You may try like:
if block
end if;
return somefakething;
no matter this return can be reached or not.
then compile will be no problem.
Jie LIANG
Internet Products Inc.
10350 Science Center Drive
Suite 100, San Diego, CA 92121
Office:(858)320-4873
[EMAIL PROTECTED]
www.ipinc.com
On Wed, 7 F
"Michael Miyabara-McCaskey" <[EMAIL PROTECTED]> writes:
> FATAL 1: btree: items are out of order (leftmost 0, stack 48, update 2)
This appears to indicate that you've got a corrupted index, possibly due
to carelessness about starting the postmaster always in the same locale
(see past discussions
Is there a simple (unix) command I can run on text files to convert
cr/lf to lf? The way I did it seemed pretty ass-backward to me (not to
mention time consuming).
-Brice
Tom Lane wrote:
>
> Brice Ruth <[EMAIL PROTECTED]> writes:
> > Here's my latest tactic: I'm guessing that the data 'corrupt
Brice Ruth <[EMAIL PROTECTED]> writes:
> Is there a simple (unix) command I can run on text files to convert
> cr/lf to lf?
You could strip out CRs entirely with
tr -d '\015'
regards, tom lane
Brice Ruth <[EMAIL PROTECTED]> writes:
> SELECT length(monographid) FROM tblpemdruglink WHERE drugid='DG-5039';
> I get 5 returned to me, even though the string is only 4 ('2008').
Okay, so you've got some invisible character in there, but not a space
(else the trim() woulda got rid of it). Tab
You could try this to see if it makes a difference
UPDATE tblpemdruglink SET monographid = substr(monographid, 1,
length(monographid) - 1)
Michael Fork - CCNA - MCP - A+
Network Support - Toledo Internet Access - Toledo Ohio
On Wed, 7 Feb 2001, Brice Ruth wrote:
> I believe we're getting close
Here's my latest tactic: I'm guessing that the data 'corruption' has
something to do with the way the data was exported from the original
database by the third party ... probably something with the cr/lf
linebreaks or something to that effect (the data field in question
happens to be the last fiel
On Thu, 08 Feb 2001 05:38, Brice Ruth wrote:
> Is there a simple (unix) command I can run on text files to convert
> cr/lf to lf? The way I did it seemed pretty ass-backward to me (not to
> mention time consuming).
This little heiroglyph will convert all text files rescued from that man's
syste
Brice Ruth <[EMAIL PROTECTED]> writes:
> Here's my latest tactic: I'm guessing that the data 'corruption' has
> something to do with the way the data was exported from the original
> database by the third party ... probably something with the cr/lf
> linebreaks or something to that effect (the dat
Run the following query:
SELECT fdb.versionid, fdb.category, pem.drugid FROM tblfdbmono fdb,
tblpemdruglink pem WHERE fdb.monographid = pem.monographid ORDER BY 1, 2,
3;
is anything returned? If not, that is your problem (no rows exists with
matching monographid's). If information is returned,
I believe we're getting closer to the problem here. When I run the
first query below, I get 0 results, which should be wrong. When I run
the query:
SELECT length(monographid) FROM tblpemdruglink WHERE drugid='DG-5039';
I get 5 returned to me, even though the string is only 4 ('2008').
However
On Wed, 7 Feb 2001, Brice Ruth wrote:
> Is there a simple (unix) command I can run on text files to convert
> cr/lf to lf? The way I did it seemed pretty ass-backward to me (not to
> mention time consuming).
perl -pi~ -e 's/\r//g' file1 file2 ... fileN
--
Dominic J. Eidson
FATAL 1: btree: items are out of order (leftmost 0, stack 48, update 2)
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
Anyone have any ideas?
I was running a script that call
heya
there are a couple of good example on how to do this in the perl
cookbook
the trim function in chapter one might help
the source code from the book is avail at ora.com
On Wed, 7 Feb 2001, Brice Ruth wrote:
> Is there a simple (unix) command I can run on text files to convert
> cr/lf to lf? The way I did it seemed pretty ass-backward to me (not to
> mention time consuming).
perl -pi -e 's/\cM\\g'
will do the trick, assuming you have Perl instaleld on your sy
I believe the cr/lf was the problem. I reran the original query:
SELECT
tblFDBMono.SequenceNumber,
tblFDBMono.SectionCode,
tblFDBMono.LineText
FROM
tblPEMDrugLink,
tblFDBMono
WHERE
(tblPEMDrugLink.MonographId = tblFDBMono.MonographId) AND
(VersionId = 'FDB-PE') AND
(Cat
I have looked a little bit at what it'd take to make SELECT INTO inside
an EXECUTE work the same as it does in plain plpgsql --- that is, the
INTO should reference plpgsql variables, not a destination table.
It looks to me like this is possible but would require some nontrivial
re-engineering insi
Tom,
> I have looked a little bit at what it'd take to make
> SELECT INTO inside
> an EXECUTE work the same as it does in plain plpgsql ---
> that is, the
> INTO should reference plpgsql variables, not a
> destination table.
> It looks to me like this is possible but would require
> some nontrivi
Hai,
I have taken pgdump of a table which contains "serial" datatype. When i
try to populate it into another database the sequence is not created.
Why it is so?
Please help me,
Ramesh
I took pgdump of the table using
pg_dump olddb -t grms_filter_table_list > tables.pgdump
i restored the table
Tom,
Once again you are a lifesaver.
Thank you. I ended up just dropping all the indexes on the table in
question, and life is now good.
-Michael
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 07, 2001 4:42 PM
> To: [EMAIL PROTECTED]
> Cc:
39 matches
Mail list logo
