SL Baur <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> Uh, did you run the "createlang" script to install plpgsql into your
>> database? It's not installed by default ...
> Why isn't it installed by default? Just asking.
Paranoia, mostly --- we weren't sure we wanted it
Tom Lane <[EMAIL PROTECTED]> writes:
> Uh, did you run the "createlang" script to install plpgsql into your
> database? It's not installed by default ...
Why isn't it installed by default? Just asking.
> At one time Bruce had made some patches to emit informative notice
> messages about implicit FROM entries, but that got turned off again
> for reasons that I forget...
It was triggered with common cases from the "outer join" syntax. It took
a while to track down since it was introduced while I
It can't be any larger than 8k (minus a bit of overhead). You can increase
this now to 32k (again, minus the same overhead) by changing BLKSZ to 32k in
the config.h header..
I'm successfully doing this in my database (which is pretty high-traffic and
pretty large).
Good luck!
-Mitch
- Origi
hi .everyine
when i want put a
long file into a field with text type . i was warning the turple is
too long and the table cann't open again.does the' text' type cann't store more than about 9,050 char
?
thank you .
xv
hai
Tom Lane wrote:
> Ryan Bradetich <[EMAIL PROTECTED]> writes:
> > This worked great! Is their a place I can change the default to 3?
> > I do not want to change all the scripts to include this :)
>
> See src/include/optimizer/cost.h. However, I am currently thinking of
> taking Hiroshi's advice
Rostislav Opocensky <[EMAIL PROTECTED]> writes:
> SELECT *
> FROM vals
> WHERE trunc_to_day(timestamp) = trunc_to_day('28.5.2000');
>
> Seq Scan on vals (cost=0.00..27.50 rows=10 width=44)
The problem here is that the optimizer will only consider an indexs
thanks much. that now works! :)
At 01:41 PM 5/30/00 -0400, Tom Lane wrote:
>mikeo <[EMAIL PROTECTED]> writes:
we've run into a problem after having deleted the line type.
when we attempt to query a table by column which is defined as float8
we get this error:
select
Hi all,
I have run into a problem trying to optimize a select from a single table.
Due to the nature of the queries our frontends issue most of the time, we
have created an index that reduces the processing time a lot. The problem
(index not being used) arose when I tried to do a select with n
mikeo <[EMAIL PROTECTED]> writes:
>>> we've run into a problem after having deleted the line type.
>>> when we attempt to query a table by column which is defined as float8
>>> we get this error:
>>>
>>> select * from test1 where tfap_id = 49232;
>>> ERROR: Unable to locate type oid 628 in cata
What is the normal way to preform a "insert with replace" on
a row in a relational database (specifically postgresql)?
I've got a database that (logically) represents a set of
items, where each item has a primary key represented by two
columns (id and name). If that key isn't in the database,
I
[EMAIL PROTECTED] writes:
> though, even that results in "ERROR: Unrecognized language specified in a CREATE
>FUNCTION: 'pl-pgsql'. Recognized languages are sql, C, internal and
> the created procedural languages."
Uh, did you run the "createlang" script to install plpgsql into your
database?
did you install the procedural language correctly?
under RedHat, you have to do the following:
(the location of the handler is different because of
packaging conventions)
CREATE FUNCTION plpgsql_call_handler () RETURNS OPAQUE AS
'/usr/lib/pgsql/plpgsql.so' LANGUAGE 'C';
CREATE TRUSTED P
Hi
You need to make the call_handler and create the language plpgsql.
Assuming postgres is installed in /usr/local/pgsql
Example:
-- Setup -- define the languages and the associated handlers
CREATE FUNCTION plpgsql_call_handler () RETURNS OPAQUE AS
'/usr/local/pgsql/lib/plpgsql.so' LANGUAGE 'C
On Tue, 30 May 2000 [EMAIL PROTECTED] wrote:
> I am running PostgreSQL 6.5.3 on RedHat Linux 6.1 on a PC.
> I am trying to use Pg/PLSQL.
>
> I even tried being conservative enough to copy the example code from
> http://www.postgresql.org/docs/user/c40874340.htm as follows:
> CREATE FUNCTION add
I am running PostgreSQL 6.5.3 on RedHat Linux 6.1 on a PC.
I am trying to use Pg/PLSQL.
I even tried being conservative enough to copy the example code from
http://www.postgresql.org/docs/user/c40874340.htm as follows:
CREATE FUNCTION add_one (int4) RETURNS int4 AS '
BEGIN
RETURN $1 +
for your perusal...
>From: Bruce Momjian <[EMAIL PROTECTED]>
>Subject: Re: [SQL] remove line type?
>To: mikeo <[EMAIL PROTECTED]>
>Date: Tue, 30 May 2000 10:48:02 -0400 (EDT)
>
>That is very strange. I would send it to the mailing lists.
>
>> hi bruce,
>> we've run into a problem after having
Jeff MacDonald <[EMAIL PROTECTED]> writes:
> gid is unique.. it's a serial..
Mph. If you assume that gid is unique then the query would give
well-defined results, but if you know it's unique then why don't
you just leave off the DISTINCT?
> funny thing is tho this worked on 6.5
No, 6.5 merely
Hi,
Jeff MacDonald:
> gid is unique.. it's a serial..
>
Then there is no point in using "DISTINCT" in the first place, is there?
> funny thing is tho this worked on 6.5
It happened to work because your gid is unique. But in the general case,
it can't work. Consider this table:
gid created
X
If so then why do you need to use "select distinct " ?!
BTW, I just tested on my 6.5.2, This query :
"Select distinct f1 from table1 order by f2 "
works the same as this one:
"select distinct f1,f2 from table1"
>From: Jeff MacDonald <[EMAIL PROTECTED]>
>Reply-To: Jeff MacDonald <[EMAIL PROTECTED
gid is unique.. it's a serial..
funny thing is tho this worked on 6.5
oh well thanks for the info.
jeff
On Tue, 30 May 2000, omid omoomi wrote:
> Hi jeff,
> I'm not sure but may be that's because you are using select distinct and so
> there would be a few rows with same "gid" but different "
gid is unique..
jeff
On Tue, 30 May 2000, Patrick FICHE wrote:
> It seems to me that it was lack of control in 6.5 version...
> For one "gid", you may have several "created" values, so Postgres is not
> able to decide which value must be taken and ordered
>
> Simple example
> gid creat
Hi jeff,
I'm not sure but may be that's because you are using select distinct and so
there would be a few rows with same "gid" but different "created" fields in
your table . And PG does not know which one to select and compare for ORDER
BY clause. If that ,you would need to change the table str
It seems to me that it was lack of control in 6.5 version...
For one "gid", you may have several "created" values, so Postgres is not
able to decide which value must be taken and ordered
Simple example
gid created
11
13
22
In which order is Postgres su
hi folks,
this query works fine in 6.5 but screwie in 7.0
7.0
gm=> SELECT DISTINCT gid FROM members
gm-> WHERE active = 't'
gm-> AND (gender = 0
gm-> AND (wantrstypemale LIKE '%Short Term%'
gm-> OR wantrstypemale like '%Marriage%'
gm-> OR wantrstypemal
On 30 May 2000, Christophe Labouisse wrote:
> I have a table (A) with a few "sibbling" tables (B and C for
You probably mean "child" tables.
> instance). When I make the following query : select id from A* where
> [condition] pgsql returns ids taken from A, B or C (which is what I
> want). Is t
I have a table (A) with a few "sibbling" tables (B and C for
instance). When I make the following query : select id from A* where
[condition] pgsql returns ids taken from A, B or C (which is what I
want). Is there a way to know to what table the id actually belong ?
--
Le cinéma en Lumière : ht
27 matches
Mail list logo
