Dan Black wrote:
Need to rename function parameters, so that their names and table fields
names are unmatched.
I don't really see a way to make the error any more obvious in the
current pl/pgsql implementation, unfortunately.
-Neil
---(end of broadcast)--
David B. wrote:
8.0.1 doesn't compile to include plpgsql.o so I can't createlang pl/pgsql.
The 8.0.1 compile does create a plpgsql.so; it is installed under
$prefix/lib.
Why don't you guys provide rpms for the major distributions anyway?
http://www.postgresql.org/ftp/binary/v8.0.1/linux/rpms/
-Ne
On Sat, Mar 19, 2005 at 11:21:54PM -0700, David B. wrote:
> 8.0.1 doesn't compile to include plpgsql.o so I can't createlang pl/pgsql.
I think you have misidentified your problem.
> Why don't you guys provide rpms for the major distributions anyway?
> I'm using mandrake and because you don't prov
The following bug has been logged online:
Bug reference: 1552
Logged by: Brian O'Reilly
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.1
Operating system: Linux 2.6.11
Description:massive performance hit between 7.4 and 8.0.1
Details:
When doing a lot of i
On Friday 18 March 2005 14:29, Stephan Szabo wrote:
> Given the error message, this seems to be the whole plpgsql caches query
> plans but we don't invalidate those plans when there are schema changes.
I already tried to execute the 'CREATE TEMP TABLE' statement using EXECUTE to
avoid cache probl
On Friday 18 March 2005 18:08, Bruce Momjian wrote:
> Uh, have you read the FAQ item about plpgsql and temporary tables?
Doesn't seems like, eh? ;-)
...sorry for the not rtfm.
---(end of broadcast)---
TIP 9: the planner will ignore your desire to c
8.0.1 doesn't compile to include plpgsql.o so I can't createlang pl/pgsql.
Why don't you guys provide rpms for the major distributions anyway? I'm
using
mandrake and because you don't provide rpms I have to use the --without
readline and zlib commands just to get it to compile. I can't find a
m
The following bug has been logged online:
Bug reference: 1553
Logged by: Dan Black
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.1
Operating system: MS Windows 2000 sp4
Description:Function arguments and table fields
Details:
1) Here is simple function
C
Roy Badami <[EMAIL PROTECTED]> writes:
> ... but all of them have (in ANSI SQL) disitinct data types.
They are distinct types, or at least different typmods, in
Postgres as well.
regards, tom lane
---(end of broadcast)---
TI
Bruce Momjian writes:
> I guess my point is that we should allow:
> select interval '1' day '1' hour
> as SQL standard
Where do you get that that's in the SQL standard?
What is in the standard is
::=
INTERVAL [ ]
::=
{ | }
Bruce Momjian writes:
> I am wondering why we allow the 'interval' data type specification to be
> after the string.
Because that's what the standard demands. Please don't muddy the waters
by introducing yet more nonstandard syntax into the discussion.
regards, tom lane
Roy> It would be
Roy>INTERVAL '1 1' DAY TO HOUR
Actually, it would be any one of the following:
INTERVAL '1 1' DAY TO HOUR
INTERVAL '1 1:00' DAY TO MINUTE
INTERVAL '1 1:00:00' DAY TO SECOND
INTERVAL '25' HOUR
INTERVAL '25:00' HOUR TO MINUTE
INTERVAL '25:00:00' HOUR
Bruce> I guess my point is that we should allow:
Bruce> select interval '1' day '1' hour
Bruce> as SQL standard and equavalent to:
Ah, I think you're misunderstanding what the SQL standard interval
literal syntax looks like.
It would be
INTERVAL '1 1' DAY TO HOUR
Essential
Roy Badami wrote:
> Bruce>select interval day to second '1 day 1 hour'
>
> Bruce> However, we don't support that syntax, only the one with
> Bruce> the specification after.
>
> Is that valid ANSI SQL?
I guess my point is that we should allow:
select interval '1' day '1'
Bruce> test=> select timestamp with time zone '2004-01-01';
Also, FWIW, according to the postgres doc this is a postgresism. The
'with time zone' clause never occurs in an ANSI timestamp literal;
whether it is a timestamp or a timestamp with time zone depends on
whether a time zone spe
Bruce> somehow. Right now we use the clause after the string as
Bruce> the date type specification, and I see you saying that the
Bruce> data value specification has to after the string. Is that
Bruce> correct?
Well, that's what 'A guide to the SQL standard' gives as the syntax
f
Roy Badami wrote:
> Bruce>select interval day to second '1 day 1 hour'
>
> Bruce> However, we don't support that syntax, only the one with
> Bruce> the specification after.
>
> Is that valid ANSI SQL?
No idea. It just seemed like the data type specification and the data
value s
Roy Badami wrote:
> Tom> Feel like hacking the code?
>
> Hmm, in principle I might take a look some time; in reality it's
> unlikely I'll have time any time soon...
>
> There are some design issues involved, though. If you have the type
> modifier, do you isnist on SQL syntax in the string?
Bruce> select interval day to second '1 day 1 hour'
Bruce> However, we don't support that syntax, only the one with
Bruce> the specification after.
Is that valid ANSI SQL?
-roy
---(end of broadcast)---
TIP 9: the planner will
19 matches
Mail list logo
