Neil Conway writes:
> Regarding the syntax for EXECUTE, it occurs to me that it could be made
> to be more similar to the PREPARE syntax -- i.e.
>
> PREPARE foo(text, int) AS ...;
>
> EXECUTE foo('a', 1);
>
> (rather than EXECUTE USING -- the effect being that prepared statements
> now look more
"Kangmo, Kim" <[EMAIL PROTECTED]> writes:
> If the index on the same class,
> two concurrent CREATE INDEX command can update pg_class.relpages
> at the same time.
Or try to, anyway. The problem here is that the code that updates
system catalogs is not prepared to cope with concurrent updates
to
A solution to this problem is not versioning catalog tables but in-place
updating them.
Of course anther transaction that wants to update the same row in the
catalog table should wait,
which leads to bad concurrency.
But this problem can be solved by commiting every DDL right after its
execution s
> would be interested to hear a valid reason why you feel the need
> to use decode().
Just let me start by saying that this is NOT for me (see the original
email in thread)! Personally, I have no trouble using CASE. However, if
I want to create an Oracle-compatibilty layer, I have to implemen
I guess two transactions updated a tuple concurrently.
Because versioning scheme allows old versions can be
read by another transaction, the old version can be updated too.
For example,
We have a row whose value is 1
create table t1 (i1 integer);
insert into t1 values(1);
And,
Tx1 executes up
if you find yourself using the decode statement, you are probably
doing something wrong. why have it, do you _need_ it?
if you are using it for display strings based on conditions,
you shouldnt be using a function to do this. it should be a table,
or something in the middle layer. try to keep th
That would get ugly in a real hurry! Oracle does get around the issue of
parameter datatypes by having automatic datatype conversions, more or
less, everything becomes a varchar2. The only real attractants to
implementing a DECODE() function is that it's one less thing to convert
when migratin
I am trying to create an aggregate function that works on whole tuples,
but the system does not find them once defined ;(
hannu=# \d users
Table "users"
Column | Type |
Modifiers
--+-+
On Thu, 2002-07-25 at 15:55, John Liu wrote:
> I've two queries -
>
> 1. emrxdbs=# explain select * from patient A where exists (select NULL from
> patient B where B.mrn=A.mrn and B.dob=A.dob and B.sex=A.sex and
> B.lastname=A.lastname and B.firstname=A.firstname group by B.mrn, B.dob,
> B.sex,
Marc Lavergne <[EMAIL PROTECTED]> writes:
> If you're asking about whether a custom function can have vararg
> parameters, the answer appears to depend on the CREATE FUNCTION
> syntax.
Can't do it, though you could imagine creating a family of functions
of the same name and different numbers of
[EMAIL PROTECTED] (Neil Conway) writes:
>> leading up to the TODO item that mentions rejecting COPY input rows
>> with the wrong number of fields (rather than silently filling with
>> NULLs as we do now).
> Yeah, I was thinking that too. Now that we have column lists in
> COPY, there is no need t
> I would like to implement a function similar to the Decode function in
> Oracle.
Take a look at the CASE WHEN ... THEN functionality. For example:
Oracle:
select decode(col1,'abc',1,'xyz',2,0) from test;
Postgresql:
select case when col1 = 'abc' then 1 when col1 = 'xyz' then 2 else 0 end
f
I've two queries -
1. emrxdbs=# explain select * from patient A where exists (select NULL from
patient B where B.mrn=A.mrn and B.dob=A.dob and B.sex=A.sex and
B.lastname=A.lastname and B.firstname=A.firstname group by B.mrn, B.dob,
B.sex, B.lastname, B.firstname having A.patseq < max(B.patseq))
Hello,
I would like to implement a function similar to the Decode function in
Oracle. I was wondering if it is possible to accept a variable number
of parameters (array??).
Thanks,
Edwin S. Ramirez
---(end of broadcast)---
TIP 5: Have you checked
> The column names and types are determined in the parser, and used in the
> planner, optimizer, and executor. I'm not sure how the backend could
> plan a join or a where criteria otherwise.
>
> Remember that the function has to look just like a table or a subselect
> (i.e a RangeVar). With a tabl
15 matches
Mail list logo
