Hi,
Thanks for your help. In fact that means 2 solutions for this:
1) select * from pdi where rtrim(pdi) = '100058'
or
2) Use VARCHAR instead of CHAR
I don't which is the best , but both are working.
Nicolas.
> -Message d'origine-
> De : Randall Lucas [mailto:[EMAIL PROTECTED]
Hi,
Sorry - I make some typo's - here is the question again.
I have a Spread Sheet which I need to make a searchable directory out
of.
I'm in two minds on a couple things so I thought I'd ask.
I"m not sure whether to have on larger table or 2 smaller one with a
join table.
This is a trim
Hi,
I have a Spread Sheet which I need to make a searchable directory out of.
I'm in two minds on a couple things so I thought I'd ask.
I"m not sure whether to have on larger table or 2 smaller one with a
join table.
This is a trimmed down version of the data.
The directory is of Camping grounds/
Dnia 2003-06-23 20:59, Użytkownik Ryan napisał:
I know this one is simple enough.
I have two tables: packages and package_log.
I must be a total space case today because I can't hammer out the sql to
get a listing of all the packages with a count() of the package_log by
package_id.
Thanks,
Ryan
I know this one is simple enough.
I have two tables: packages and package_log.
paulsonsoft=# \d packages
Table "public.packages"
Column | Type |Modifiers
-+-+---
On Monday 23 Jun 2003 2:58 pm, Markus Bertheau wrote:
> -- Suppose I have several types of foos
>
> create table foo_types (
> foo_type_id serial primary key,
> foo_name text not null
> );
>
> -- And the foos itself:
>
> create table foo (
> foo_id serial primary key,
> foo_type_id
В Пнд, 23.06.2003, в 20:34, Michael A Nachbaur пишет:
> On Monday 23 June 2003 11:16 am, Markus Bertheau wrote:
> > В Пнд, 23.06.2003, в 19:32, Michael A Nachbaur пишет:
> > > Instead of using the "serial" datatype, you can set it to "int4 PRIMARY
> > > KEY DEFAULT nextval(foo_type_id_seq)" and you
On Monday 23 June 2003 11:16 am, Markus Bertheau wrote:
> В Пнд, 23.06.2003, в 19:32, Michael A Nachbaur пишет:
> > Instead of using the "serial" datatype, you can set it to "int4 PRIMARY
> > KEY DEFAULT nextval(foo_type_id_seq)" and you can manually create the
> > sequence "foo_type_id_seq".
> >
>
В Пнд, 23.06.2003, в 19:32, Michael A Nachbaur пишет:
> Instead of using the "serial" datatype, you can set it to "int4 PRIMARY KEY
> DEFAULT nextval(foo_type_id_seq)" and you can manually create the sequence
> "foo_type_id_seq".
>
> This way all the tables share the same sequence.
Yeah, but I
Randall Lucas <[EMAIL PROTECTED]> writes:
> The LIKE operator takes a pattern, and since your pattern did not
> specify a wildcard at the end, it didn't exactly match the padded
> string.
> This behavior does seem kind of confusing;
Yeah. As of CVS tip, the system is actually going out of its
Instead of using the "serial" datatype, you can set it to "int4 PRIMARY KEY
DEFAULT nextval(foo_type_id_seq)" and you can manually create the sequence
"foo_type_id_seq".
This way all the tables share the same sequence.
On Monday 23 June 2003 06:58 am, Markus Bertheau wrote:
> -- Suppose I have
-- Suppose I have several types of foos
create table foo_types (
foo_type_id serial primary key,
foo_name text not null
);
-- And the foos itself:
create table foo (
foo_id serial primary key,
foo_type_id int not null references foo_types,
foo_general_data1 text
);
-- 1st sp
> select id from data where dec < 2.0;
> ERROR: convert_numeric_to_scalar: unsupported type 354210
Domains exposed (and introduced) a number of interesting issues in
regards to type switching for these things.
Cast the 2.0 value to the domain:
CAST(2.0 AS physreal)
or quote it and let t
On Mon, 23 Jun 2003, L.V.Boldareva wrote:
> Hello!
>
> many people posted their answer to this simple question. however,
> neither
> CREATE TABLE AS
> nor
> SELECT INTO
>
> do not take care about keys and triggers, etc.
>
> The commands above only copy the structure of the table, and the data.
Hi Nicholas,
CHAR fields, as opposed to VARCHAR, are blank-padded to the set length.
Therefore, when you inserted a < 25 character string, it got padded
with spaces until the end.
Likewise, when you cast '100058' to a CHAR(25) in the = below, it
gets padded, so it matches.
The LIKE operat
Title: Urgent Help : Use of return from function/procedure.
- Original Message -
From:
Anagha
Joshi
To: [EMAIL PROTECTED]
Sent: Sunday, June 22, 2003 11:42
PM
Subject: [SQL] Urgent Help : Use of
return from function/procedure.
Hi, I'm new to
postgres and
Hello!
many people posted their answer to this simple question. however,
neither
CREATE TABLE AS
nor
SELECT INTO
do not take care about keys and triggers, etc.
The commands above only copy the structure of the table, and the data.
Are there any workarounds fr copying the table as a whole object?
AgentM <[EMAIL PROTECTED]> writes:
> PostgreSQL 7.3.2:
> physreal is the domain of numeric(20,14).
> ERROR: convert_numeric_to_scalar: unsupported type 354210
This is fixed in 7.3.3.
regards, tom lane
---(end of broadcast)-
Hi,
I've got a table , pdi, with a field pro_id defined as char(25). One fied
og this table contains the string '100058' plus spaces to fill the 25
length (ie pro_id = '100058 ').
When I run:
select * from pdi where pdi = '100058' the row is returned.
When I ru
On Monday 23 Jun 2003 10:09 am, Tomasz Myrta wrote:
> Dnia 2003-06-23 10:54, Użytkownik Richard Huxton napisał:
> > Hmm - I think your problem is going to come before that. Any time you do
> > an INSERT, PostgreSQL is going to need to know the types of all the
> > columns involved.
> >
> > For this
On Monday 23 Jun 2003 6:42 am, Anagha Joshi wrote:
> Hi,
> I'm new to postgres and using version 7.2.4
>
> I've created a trigger and function which does the following:
> trigger 'T' fires after insert on a spcific table takes place
> and it executes function 'F'
>
> Function 'F' returns the
Dnia 2003-06-23 10:54, Użytkownik Richard Huxton napisał:
Hmm - I think your problem is going to come before that. Any time you do an
INSERT, PostgreSQL is going to need to know the types of all the columns
involved.
For this sort of thing, I try to keep all the related bits (initial function,
On Monday 23 Jun 2003 9:39 am, Tomasz Myrta wrote:
> Dnia 2003-06-23 10:29, Użytkownik Richard Huxton napisał:
> > Look into views - you'll need to provide triggers to handle the
> > update/inserts.
>
> I think view won't change too much - there is not too much difference for
> this case between cr
Dnia 2003-06-23 10:29, Użytkownik Richard Huxton napisał:
Look into views - you'll need to provide triggers to handle the
update/inserts.
I think view won't change too much - there is not too much difference for this
case between creating view and empty table with trigger returning null.
I was th
On Sunday 22 Jun 2003 10:23 pm, Tomasz Myrta wrote:
> Hi
> I have another virtual problem, currently without any examples ;-)
>
> Let's say we have some pl/pgsql function which puts result into table1.
> This flat table must be normalized and put into table2. Sometimes 1 row
> from table1 = 1 row f
PostgreSQL 7.3.2:
Here is a piece of a table definition:
CREATE TABLE data
(
id SERIAL PRIMARY KEY,
description TEXT,
ra physreal,
dec physreal,
z physreal,
...);
physreal is the domain of numeric(20,14).
Then I created an index across ra,dec, and z (one index). I really
haven't done anything else
26 matches
Mail list logo
