Tom Lane wrote:
> > If you SELECT 'abc'::varchar(6)::varchar, the end type is varchar(6).
>
> Yeah, this is exactly what's happening --- if you look at gram.y,
> LOCALTIMESTAMP is expanded to "'now'::text::timestamp(6)". I am
> unconvinced that the (6) is a very good idea though. The code says
>
Rod Taylor <[EMAIL PROTECTED]> writes:
> On Thu, 2005-06-23 at 22:27 +0200, Markus Bertheau wrote:
>> Dnia 23-06-2005, czw o godzinie 16:19 -0400, Rod Taylor napisa³(a):
>>> The data types are different, as one has the timestamp to (6) decimal
>>> places after seconds.
>>
>> That's strange. I expl
On Thu, 2005-06-23 at 22:27 +0200, Markus Bertheau wrote:
> Dnia 23-06-2005, czw o godzinie 16:19 -0400, Rod Taylor napisał(a):
>
> > The data types are different, as one has the timestamp to (6) decimal
> > places after seconds.
>
> That's strange. I explicitly specified ::TIMESTAMP on both the
Dnia 23-06-2005, czw o godzinie 16:19 -0400, Rod Taylor napisał(a):
> The data types are different, as one has the timestamp to (6) decimal
> places after seconds.
That's strange. I explicitly specified ::TIMESTAMP on both the view and
the table. Is that not unambiguous?
Markus
--
Markus Berthe
On Thu, 2005-06-23 at 22:03 +0200, Markus Bertheau wrote:
> Hi,
>
> it seems to me that the following should work but it fails:
>
> CREATE VIEW co AS SELECT LOCALTIMESTAMP::TIMESTAMP AS ov WHERE FALSE;
> CREATE TABLE link (ov TIMESTAMP);
> CREATE OR REPLACE VIEW co AS SELECT ov FROM link;
The da
Dnia 23-06-2005, czw o godzinie 22:03 +0200, Markus Bertheau napisał(a):
> Hi,
>
> it seems to me that the following should work but it fails:
>
> CREATE VIEW co AS SELECT LOCALTIMESTAMP::TIMESTAMP AS ov WHERE FALSE;
> CREATE TABLE link (ov TIMESTAMP);
> CREATE OR REPLACE VIEW co AS SELECT ov FRO
Hi,
it seems to me that the following should work but it fails:
CREATE VIEW co AS SELECT LOCALTIMESTAMP::TIMESTAMP AS ov WHERE FALSE;
CREATE TABLE link (ov TIMESTAMP);
CREATE OR REPLACE VIEW co AS SELECT ov FROM link;
Markus
--
Markus Bertheau <[EMAIL PROTECTED]>
signature.asc
Description: T
I'm not sure if this is the best thing to do in all occasions, but I have
found a great speed increase using unions over group by.
select fkey, uid, seq2 from mytable where seq2 > 2 and seq1 = ( select
min(seq1) from mytable);
union
select fkey, uid, seq2 from mytable where seq2 > 2 and seq1 =
Markus Bertheau <[EMAIL PROTECTED]> writes:
> Can pg transform
> SELECT * FROM (
> SELECT 'foo' AS class, id FROM foo
> UNION ALL
> SELECT 'bar' AS class, id FROM bar
> ) AS a WHERE class = 'foo'
[ experiments... ] Yes, if you spell it like this:
regression=# explain SELECT *
I have a table that looks like this:CREATE TABLE my_table ( pkey serial PRIMARY KEY, fkey int NOT NULL REFERENCES my_other_table( pkey ), uid int NOT NULL REFERENCES user( pkey ), seq1 int, seq2 int);Basically, for each fkey that exists in my_table, there is a sequence represented by
Hi,
Can pg transform
SELECT * FROM (
SELECT 'foo' AS class, id FROM foo
UNION ALL
SELECT 'bar' AS class, id FROM bar
) AS a WHERE class = 'foo'
into
SELECT 'foo' AS class, * FROM foo?
The subselect is a view here, that's why I don't just use the second
query.
Markus
-
After delete worked and the a foreach execute update seems to work best.
Below is a satisfactory test set.
-- create test table
CREATE TABLE test1 (
a int,
b int,
c int);
-- create resort function
CREATE OR REPLACE FUNCTION resort_test1() RETURNS TRIGGER AS '
DECLARE
eachrow RECORD;
innerrow
12 matches
Mail list logo
