On Tue, Aug 16, 2005 at 01:54:13AM -0300, Marc G. Fournier wrote:
>
> CREATE TABLE customers (
> customer_id SERIAL,
> monthly_balance DECIMAL(7,2)[12]
> );
>
> Is it possible to create an INDEX on customers.monthly_balance such that I
> could do something like:
>
> SELECT * FROM customers W
Can't seem to find anything concerning this in the docs, and I don't think
it is something that can be done, but figure I'll double check before I
write it off completely ...
If I create a table:
CREATE TABLE customers (
customer_id SERIAL,
monthly_balance DECIMAL(7,2)[12]
);
Is it poss
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Mon, 15 Aug 2005, Dario Bahena Tapia wrote:
>> The final result seems to be the same, I just was curious about the
>> standard behavior. Does the SQl says something about this execution
>> order?
> I believe SQL defines the order to pay attention to p
On Mon, 15 Aug 2005, Dario Bahena Tapia wrote:
> The final result seems to be the same, I just was curious about the
> standard behavior. Does the SQl says something about this execution
> order?
I believe SQL defines the order to pay attention to parens, so A join (B
join C) style clauses result
Michael Fuhr <[EMAIL PROTECTED]> writes:
> On Mon, Aug 15, 2005 at 08:21:23PM -0400, Tom Lane wrote:
>> Given that we consider trailing spaces in char(n) to be semantically
>> insignificant, would it make sense to strip them before doing the
>> regex pattern match?
> How standards-compliant would
On Mon, Aug 15, 2005 at 08:21:23PM -0400, Tom Lane wrote:
> Michael Fuhr <[EMAIL PROTECTED]> writes:
> > The CHAR(3) specification causes the value to be space-padded, so
> > '1' becomes '1 ' (the digit "one" followed by two spaces).
>
> Actually, we seem to be going out of our way to make this c
Quoting Simon Law <[EMAIL PROTECTED]>:
>
> CREATE TABLE tablename (field INTERVAL);
> INSERT INTO tablename VALUES('3 weeks');
> SELECT field FROM tablename;
> | 21 days |
>
> The output shows up in days or months but not weeks how do i make
Internally, INTERVAL is stored as a 12byte tuple
Michael Fuhr <[EMAIL PROTECTED]> writes:
> The CHAR(3) specification causes the value to be space-padded, so
> '1' becomes '1 ' (the digit "one" followed by two spaces).
Actually, we seem to be going out of our way to make this case fail.
Given that we consider trailing spaces in char(n) to be se
CREATE TABLE tablename (field INTERVAL);
INSERT INTO tablename VALUES('3 weeks');
SELECT field FROM tablename;
_
| field |
|--|
| 21 days |
||
The output shows up in days or months but not weeks how do i make
it output in weeks?
Any help with this wi
>> Any reason you are using char(3) instead of varchar(3)?
>The numbers will have 2 or 3 digits so I tried to save some space :)
Well, smallint is only 2 bytes, so it would be more compact than either
char(3) or varchar(3).
Dmitri
The information transmitted is intended only for the person or en
On Mon, 15 Aug 2005 18:37:52 -0400
"Dmitri Bichko" <[EMAIL PROTECTED]> wrote:
> I'm guessing it's because char gets padded with spaces to the
> specified length.
argh. Thank you.
> Any reason you are using char(3) instead of varchar(3)?
The numbers will have 2 or 3 digits so I tried to save s
On Tue, Aug 16, 2005 at 12:19:50AM +0200, Sebastian Siewior wrote:
>
> create table t (
> col CHAR (3) CONSTRAINT numonly_col CHECK ( col ~ '^\\d+$' )
> );
>
> This check avoids non-numbers like '1a1' and allows '123'. For some
> reason, I'm unable to find out why, it also avoids things like '1
Can someone PLEASE do something about this guy?
It's rather annoying getting this after every single post, and I am certainly
not going to justify my intentions to his fancy spam service.
Dmitri
-Original Message-
From: AntiSpam UOL [mailto:[EMAIL PROTECTED]
Sent: Monday, August 15, 20
Sebastian Siewior schrob:
> Hello hopefully correct List,
perfectly.
> I was trying to do something that is not working as it supposed to.
> First I created a table:
>
> create table t (
> col CHAR (3) CONSTRAINT numonly_col CHECK ( col ~ '^\\d+$' )
> );
>
> This check avoids non-numbers like
I'm guessing it's because char gets padded with spaces to the specified
length.
Any reason you are using char(3) instead of varchar(3)? And why are you
storing numbers as a string, anyway? If you defined the column as a
numeric type, postgres will tell you if you try to insert something
non-nume
Hello hopefully correct List,
I was trying to do something that is not working as it supposed to.
First I created a table:
create table t (
col CHAR (3) CONSTRAINT numonly_col CHECK ( col ~ '^\\d+$' )
);
This check avoids non-numbers like '1a1' and allows '123'. For some
reason, I'm unable to
Is there a reason not to build it in as a sub-query?E.g., if you have a function get_count( int ): SELECT count(b_column)FROM some_tableWHERE some_field_1 in ( SELECT a_column FROM a_table WHERE some_condition)AND some_field_2 = $2; --Thomas F. O'ConnellCo-Founder, Information ArchitectSit
santiago, here are the code snippets for you that come right out of a
trigger that is being used in production today. This trigger is an after
update trigger, so take that into consideration if needed. I think it
will do for you what you need to do.
CREATE OR REPLACE FUNCTION update_rpt_history()
On Wed, 10 Aug 2005 [EMAIL PROTECTED] wrote:
> I thought that the parenthesis in the table expression
> (FROM clause), could be used to indicate the desired
> evaluation order. But, I tried with a couple of samples
> and the explain command returned me the same result; no matter
> what parentheses
santiago wrote:
Hi
thanks all for your answers !
to Lane Van Ingen:
my purpose is to write a trigger on update so that 'users' might then us
update without having to perform the if found.
Of course the other option is to make sure there is always a row
available to update. Impossible to say
On Wed, 10 Aug 2005 05:03:47 +0200, tgh002 <[EMAIL PROTECTED]> wrote:
I am using a insert statement like:
INSERT INTO newtable
SELECT field1, field2 FROM anothertable
newtable structure is: serial, varchar, varchar
What syntax do I use to insert the serial field? Ive tried something
like:
Lucas Grijander wrote:
Hi:
I've just migrated from Linux/PostgreSQL 7.2 to
Windows/PostgreSQL 8.0.3. I have a large view. When I make:
"Select . WHERE mydate = 'anydate'"
the view lasts 19 seconds to complete. But, when I make:
"Select . WHERE mydate >= 'anydate'"
the view lasts 7 mi
22 matches
Mail list logo
