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
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:
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
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, 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()
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
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
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
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 '1a1'
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,
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' and
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 some
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
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
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
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 (years,
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 case fail.
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 that be?
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
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
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 WHERE
21 matches
Mail list logo
