On Tue, 2002-06-18 at 16:58, Digital Wokan wrote:
> So I suppose since he's referring to a field, to pull it in all
> uppercase, he'd use...
> SELECT "ABC" from mytable;
> Am I correct?
Yes. Same with functions too I guess. Sequences were tricky,
I think.. you needed: currval('"mytable_ABC_
I usually use an SELECT with an OUTER JOIN that uses the foreign key with
a USING or ON clause. Then in the where clause I look for any records
where some field from the primary key table that is NOT NULL is null.
Something like:
SELECT oid FROM fktbl LEFT OUTER JOIN pktbl USING(keyname) WHERE
On Tue, 18 Jun 2002, Cliff Wells wrote:
> Hello,
>
> I'm porting an application's data from a proprietary format into PostgreSQL
> 7.2.1. I'm using ecpg and I basically follow this process:
>
> create tables
> create indexes
> import data
> add foreign key constraints
>
> I have to add the forei
So I suppose since he's referring to a field, to pull it in all
uppercase, he'd use...
SELECT "ABC" from mytable;
Am I correct?
David Stanaway wrote:
> On Mon, 2002-06-17 at 20:25, Scot Wilcoxon wrote:
>
>>I've seen a few comments of people encountering this problem, but not
>>yet a solution:
Hello,
I'm porting an application's data from a proprietary format into PostgreSQL
7.2.1. I'm using ecpg and I basically follow this process:
create tables
create indexes
import data
add foreign key constraints
I have to add the foreign key constraint last as otherwise the import will fail
as
On Tue, 2002-06-18 at 15:26, Tom Lane wrote:
> "Nick Fankhauser" <[EMAIL PROTECTED]> writes:
> > Hmmm... I'm confused. It works for us. When I make this change in
> > postmaster.conf for our v7.2 install, it has the desired effect.
>
> I'm sorry, I thought that was a thinko for postgresql.conf.
"Nick Fankhauser" <[EMAIL PROTECTED]> writes:
> Hmmm... I'm confused. It works for us. When I make this change in
> postmaster.conf for our v7.2 install, it has the desired effect.
I'm sorry, I thought that was a thinko for postgresql.conf. Evidently
not --- it must be a file that sets up enviro
Hmmm... I'm confused. It works for us. When I make this change in
postmaster.conf for our v7.2 install, it has the desired effect. Perhaps
this file is specific to the Debian package. Is postmaster.conf generally
used in all distributions?
Here is the documentation I found in that file:
# How (b
"Nick Fankhauser" <[EMAIL PROTECTED]> writes:
> in postmaster.conf, add a line that looks something like this:
> PGDATESTYLE=ISO,European
I do not believe that will work in any released version. It will work
to set PGDATESTYLE as an environment variable in the postmaster's
environment, however.
Title: RE: [ADMIN] Uppercase field names not found
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
SELECT "ABC" FROM mytable;
>> -Original Message-
>> From: Scot Wilcoxon [mailto:[EMAIL PROTECTED]]
>> Sent: 18 June 2002 02:26
>> To: [EMAIL PROTECTED]
>> Subject: [ADMIN] Uppercase f
Jeff Boes <[EMAIL PROTECTED]> writes:
> We are experiencing a fairly predictable lock-up in the overnight VACUUM
> ANALYZE maintenance script. The VACUUM gets to the pg_class table and
> then stops, obviously waiting for something else to give up control of
> the table. The VACUUM script resumes
On Mon, 2002-06-17 at 20:25, Scot Wilcoxon wrote:
> I've seen a few comments of people encountering this problem, but not
> yet a solution:
>
> Upper case field names in commands are forced to lower case and then not
> found.
>
> I was able to create a table with a field called "ABC".
>
> "S
I've seen a few comments of people encountering this problem, but not
yet a solution:
Upper case field names in commands are forced to lower case and then not
found.
I was able to create a table with a field called "ABC".
"SELECT ABC FROM mytable;"
emits the error
"no such attribute or funct
13 matches
Mail list logo
