[BUGS] Cursor case-sensitivity
Not sure if this is known or not, but apparently cursors names are not
appropriately case-lowered when dealing with functions that return cursors.
Using the example straight from the documentation at
http://developer.postgresql.org/docs/postgres/plpgsql-cursors.html:
This works:
BEGIN;
SELECT reffunc('funccursor');
FETCH ALL IN funccursor;
COMMIT;
But this doesn't work:
BEGIN;
SELECT reffunc('funcCursor');
FETCH ALL IN funcCursor;
COMMIT;
This 2nd one gives a warning in the log of:
WARNING: PerformPortalFetch: portal "funccursor" not found.
-Dave
_
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] Cursor case-sensitivity
"Key88 SF" <[EMAIL PROTECTED]> writes:
> BEGIN;
> SELECT reffunc('funcCursor');
> FETCH ALL IN funcCursor;
> COMMIT;
> WARNING: PerformPortalFetch: portal "funccursor" not found.
I don't think this is a bug. You should have written
FETCH ALL IN "funcCursor";
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] No error reported when field in subselect is not part of the table but exists in the main table.
There is no error reported when a field in the subselect is not part of the subselect table but exists in the main table. Try This: nsd=# create table a ( f1 int, f2 text); CREATE nsd=# create table b ( f3 int, f4 text); CREATE nsd=# select * from a where f1 in ( select f1 from b); f1 | f2 + (0 rows) nsd=# select version(); version - PostgreSQL 7.2.1 on i686-pc-linux-gnu, compiled by GCC 2.96 (1 row) ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] No error reported when field in subselect is not part of
On Mon, 27 Jan 2003, Jean-Luc Lachance wrote: > There is no error reported when a field in the subselect is not part of > the subselect table > but exists in the main table. > > Try This: > > nsd=# create table a ( f1 int, f2 text); > CREATE > nsd=# create table b ( f3 int, f4 text); > CREATE > nsd=# select * from a where f1 in ( select f1 from b); > f1 | f2 > + > (0 rows) That's because f1 is taken as an outer reference. I think that's the expected/correct behavior. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] recent (just got from cvs) build doesn't run nicely
hi i just got newest checkout from cvs. it builded fine. it installed. than i do initdb: (pgdba@depeszws[pts/11]) 21:35:05 [~] $ echo $PGDATA /home/pgdba/work/data (pgdba@depeszws[pts/11]) 21:35:10 [~] $ initdb -W The files belonging to this database system will be owned by user "pgdba". This user must also own the server process. The database cluster will be initialized with locale C. Fixing permissions on existing directory /home/pgdba/work/data... ok creating directory /home/pgdba/work/data/base... ok creating directory /home/pgdba/work/data/global... ok creating directory /home/pgdba/work/data/pg_xlog... ok creating directory /home/pgdba/work/data/pg_clog... ok creating template1 database in /home/pgdba/work/data/base/1... ok creating configuration files... ok initializing pg_shadow... ok Enter new superuser password: Enter it again: setting password... ok enabling unlimited row size for system tables... ok initializing pg_depend... /home/pgdba/work/bin/initdb: line 716: 26438 Segmentation fault "$PGPATH"/postgres $PGSQL_OPT template1 >/dev/null < do you have any idea on what is wrong? depesz -- hubert depesz lubaczewski http://www.depesz.pl/ > wynajmę mieszkanie - 60 metrów, 3 pokoje, piastów - od lutego (po < -=> remoncie) interesuje cię - napisz: [EMAIL PROTECTED]<=- ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] recent (just got from cvs) build doesn't run nicely
Hubert depesz Lubaczewski <[EMAIL PROTECTED]> writes: > i just got newest checkout from cvs. > it builded fine. > [but] > initializing pg_depend... /home/pgdba/work/bin/initdb: line 716: 26438 Segmentation >fault "$PGPATH"/postgres $PGSQL_OPT template1 >/dev/null
Re: [BUGS] No migration path for MONEY
They are probably better off just changing the column data type, _and_
we need someone to get MONEY working as an extented NUMERIC type.
---
Josh Berkus wrote:
> Folks,
>
> Bug reported off IRC:
>
> MONEY Type cannot be cast to any other type, preventing migration from this
> depreciated data type.
>
> Affects: 7.2.3, 7.3.1
> Frequency: 100% Reproducable
> Effect When Occurring: Unable to convert, query data
> Difficulty of Fix: Easy, probably
> Certianty of Diagnosis: 100%
>
> On both 7.2.3 and 7.3.1 all of the following statements will fail:
>
> select cast('40.00'::MONEY as NUMERIC);
> select cast('40.00'::MONEY as DOUBLE);
> select cast('40.00'::MONEY as VARCHAR);
> select "numeric"('40.00'::MONEY);
> select to_char('40.00'::MONEY, '999.');
>
> This means that someone who has inherited or upgarded a 6.5 database with
> MONEY columns has no way to migrate them to NUMERIC columns other than an
> external language script or dump and reload from COPY file.
>
> I propose that we need to restore the CAST(MONEY AS NUMERIC) function so that
> users can migrate old databases to the new data type. In later versions of
> postgres, I suggest that MONEY be abandoned as a true data type and instead
> become a DOMAIN of NUMERIC for those converting.
>
> --
> -Josh Berkus
> Aglio Database Solutions
> San Francisco
>
>
> ---(end of broadcast)---
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] No migration path for MONEY
Bruce, > They are probably better off just changing the column data type, _and_ > we need someone to get MONEY working as an extented NUMERIC type. Apparently D'Arcy McCain is going to do this. Go, D'arcy! -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] Bug #880: COMMENT ON DATABASE depends on current database
Bruce Momjian writes: > Do we have psql -l to connect to all the databases to collect comments? > I guess we could _try_ to connect to as many databases as possible, but > it seems a little overly complex to me. What do others think? I tend to think that the functionality to give comments to databases should either be redone to work right (for example by storing the comment in a global table (but think about the encoding problems)) or be ripped out. Right now the feature to give a comment to a database you presumably already know (since you connected to it) does not seem to justify the confusion it causes. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] Bug #880: COMMENT ON DATABASE depends on current database
Peter Eisentraut wrote: > Bruce Momjian writes: > > > Do we have psql -l to connect to all the databases to collect comments? > > I guess we could _try_ to connect to as many databases as possible, but > > it seems a little overly complex to me. What do others think? > > I tend to think that the functionality to give comments to databases > should either be redone to work right (for example by storing the comment > in a global table (but think about the encoding problems)) or be ripped > out. Right now the feature to give a comment to a database you presumably > already know (since you connected to it) does not seem to justify the > confusion it causes. Good analysis. Is removal actually the best solution? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Bug #880: COMMENT ON DATABASE depends on current
> > I tend to think that the functionality to give comments to databases > > should either be redone to work right (for example by storing the comment > > in a global table (but think about the encoding problems)) or be ripped > > out. Right now the feature to give a comment to a database you presumably > > already know (since you connected to it) does not seem to justify the > > confusion it causes. > > Good analysis. Is removal actually the best solution? Front-ends like pg_admin actually make pretty good use out of it. -- Rod Taylor <[EMAIL PROTECTED]> PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
