7.4.X CVS has:
if (conn->sversion >= 70300)
query = "select proname, oid from pg_catalog.pg_proc "
"where proname in ("
"'lo_open', "
"'lo_close', "
"'lo_creat', "
"'lo_unlink', "
"'lo_lseek', "
"'lo_t
pgsql-bugs:
I wrote a plpgsql function that does a fairly expensive calculation on
its input, and want to peform a query that:
1. Selects certain rows from a table, then
2. Calls my function on the selected rows
So I wrote a query and used a subselect to first select the rows, and
then used the
Janko Richter <[EMAIL PROTECTED]> writes:
> I have found the bug.
> Unfortunately, I have a table called public.pg_proc within my database
> with the same structure of pg_catalog.pg_proc. I did a test with it and
> forgot to drop it.
> Within postgresql-7.4.1/src/interfaces/libpq/fe-lobj.c near l
I have found the bug.
Unfortunately, I have a table called public.pg_proc within my database
with the same structure of pg_catalog.pg_proc. I did a test with it and
forgot to drop it.
Within postgresql-7.4.1/src/interfaces/libpq/fe-lobj.c near line 555 is
a query call as
res = PQexec(conn
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
> I have found that in PG 7.4.1 the dump_pg command
> no longer seems to work with upper case table names.
Works fine for me:
regression=# create table "SA_SSN" ("F1" int);
CREATE TABLE
regression=# \q
$ pg_dump -t SA_SSN regression
-- (produces
Joe Conway <[EMAIL PROTECTED]> writes:
> I can reproduce this with cvs tip -- I'll check into it.
It's no surprise --- plpgsql's RAISE doesn't take anything but a string
literal for the format, and unadorned variable names for the additional
parameters. It ought to be generalized some time ...
The following bug has been logged online:
Bug reference: 1100
Logged by: Bill Erickson
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.4
Operating system: Solaris 9
Description:pd_dump doesn't work with upper case table names
Details:
I have found that i
Josh Berkus wrote:
Bug: Cannot Use Arrays with Raise Notice in PL/pgSQL.
Version Tested: 7.4.1
Severity: Annoyance
Description:
Attempting to pass an array element to Raise Notice in PL/pgSQL will produce a
parse error:
I can reproduce this with cvs tip -- I'll check into it.
Thanks,
Joe
--
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> PostgreSQL Bugs List wrote:
>> CREATE FUNCTION test1 (int) RETURNS int LANGUAGE sql
>> AS 'not even SQL';
>> ERROR: syntax error at or near "not" at character 1
> The error message refers to the function body, which is parsed
> separately and theref
Richard Huxton <[EMAIL PROTECTED]> writes:
> The rule should only be applied once. The rule system basically rewrites the
> insert you supply into two other insert queries (from/to). It will not
> generate one query for each row in quips_transactions (which is what you
> want). You probably need
PostgreSQL Bugs List wrote:
> CREATE FUNCTION test1 (int) RETURNS int LANGUAGE sql
> AS 'not even SQL';
> ERROR: syntax error at or near "not" at character 1
>
> You may notice that word "not" is not at character 1,
> where there is "CREATE".
The error message refers to the function body, whi
The following bug has been logged online:
Bug reference: 1099
Logged by: Fabien Coelho
Email address: [EMAIL PROTECTED]
PostgreSQL version: 7.5 Dev
Operating system: linux debian
Description:bad syntax error localisation
Details:
The example is in the regressio
On Thursday 11 March 2004 06:45, PostgreSQL Bugs List wrote:
> The following bug has been logged online:
>
> Bug reference: 1098
> Logged by: Tim Burgess
> Email address: [EMAIL PROTECTED]
> Description:Multiple ON INSERT rules not applied properly in the
> case of INSER
13 matches
Mail list logo
