Re: CVS tip compile failure (was Re: [HACKERS] Missing array support)
On Sat, 28 Jun 2003, Joe Conway wrote: > > Do I need to do something to get new language files? > > causing me problems. Did a "cvs add" get missed somewhere, or am I doing > something wrong? Yes, a couple of cvs add was forgotten. Peter made an update with the comment "Merge PO file updates from 7.3 branch.". I checked out a new copy with tag REL7_3_2 and there are the missing files (at least the one I checked, but probably the rest also). -- /Dennis ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PHP/PgSQL *and* libpq ...
On Wed, 25 Jun 2003, Robert Treat wrote: > Seems like we should also allow for a windows specific distribution of libpq > as well. I thought that the win32 stuff was being included as part of the base distribution? IF so, wouldn't such already be included in any libpq.tar.gz we created? Is there a reason why we'd need a libpq-win.tar.gz (assuming that that is what you are suggesting?) ... ? > > Robert Treat > > On Tuesday 24 June 2003 10:43 pm, Bruce Momjian wrote: > > Added to TODO: > > > > * Allow creation of a libpq-only tarball > > > > --- > > > > The Hermit Hacker wrote: > > > Just a side bar to the whole thread about PHP/MySQL ... I realize that > > > libpq is intwined with the backend right now, but if anyone could think > > > of a way of at least adding a make target that would create a > > > libpq.tar.gz distribution, I believe it would go a long way towards > > > making it easier for ppl to add/compile in PgSQL support into PHP ... > > > right now, to do so, you have to download an 8Meg file to get libpq ... > > > if it could be reduced to a <.5Meg tar.gz file: > > > > > > svr1# du -sk libpq > > > 532 libpq > > > > > > it would be less onerous to download and add the support in ... > > > > ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] IPv6 datatype patch
ftp://ftp.kame.net/pub/kame/misc/ has IPv6 datatype patch (makes "inet" type handle both IPv4 and IPv6) for 7.3.2. let me know how i can proceed/help. itojun ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] lru cache replacement
[EMAIL PROTECTED] wrote: > > I tried to implement LRU-2 awhile ago, and got discouraged when I > > couldn't see any performance improvement. But I was using pgbench as > > the test case, and failed to think about its lack of seqscans. > > Yes , lru-2 will behave like LRU under 'normal' load. it will detect > sequential scans and adapt to it. I think that was why you didn't > see any substantial gain in cache hits. though I think ARC does a better > job. LRU-2 also has logaritmic complexity overhead. > > The ARC guys have tested with real traces from a Db of a large insurrance > company and the results were quite encouraging. (a lot of other traces > where examined as well) > > > We could probably resurrect that code for comparison to 2Q, if anyone > > can devise more interesting benchmark cases to test. > > As i stated before, i'm willing to implement ARC and to see how they all > compare. Great. -- 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 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
[HACKERS] ruleutils.c writer Jan Wieck
Hi Can someone give me the email ID of Jan Wieck who has written that code in ruleutils.c? It is urgent. Sumit ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Table Partitioning
I'm not subscribed to this list, so please CC me on replies. I wanted to know when table partitioning was supposed to be completed. I was under the impression that work had been done about 5 months ago or more and that all that was needed was testing. Could someone please advise? We're looking at moving to postgres from oracle. Thanks much. -- Austin Gonyou <[EMAIL PROTECTED]> Coremetrics, Inc. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] lru cache replacement
On Tue, 24 Jun 2003 10:27:09 -0400 Tom Lane <[EMAIL PROTECTED]> wrote: > I tried to implement LRU-2 awhile ago, and got discouraged when I > couldn't see any performance improvement. But I was using pgbench as > the test case, and failed to think about its lack of seqscans. How about cache hit rate? > BTW, when you were running your test case, what shared_buffers did you > use? I use 16,64,256 and 4096. --- Yutaka tanida<[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: [HACKERS] [GENERAL] Physical Database Configuration
> Well, correct solution is to implement tablespaces on which objects like > databases, tables and indexes can be put. I've not looked at the SQL standard, but it seems to me like the order should be: Databases Tablespaces Schemas Objects (tables, indexes, functions, etc.) And it really isn't hierarchical. As I understand them (based on my Oracle background), tablespaces, unlike schemas, do NOT create a layer of data abstraction. That is to say, while the same table name can exist in multiple schemas, only one instance of a given table name within a given schema can exist, regardless of what tablespace it is in. That makes the tablespace a property of an object. Whether or not two databases can share tablespaces isn't clear to me, though as a DBA I can think of good reasons why they probably shouldn't do so, I'm not sure if that is an absolute. > I have no idea what is the status of that effort right now. You can search the > archives or I hope this kicks a fresh discussion..:-) I'm game, though I'm also not ready to lead such a project, probably not even the discussion on it. -- Mike Nolan ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] Many Pl/PgSQL parameters -> AllocSetAlloc(128)?
How come you didn't get a "No such function with those arguments" error that I always
get when I do that?
planning=# create function oops (integer) returns int language pltcl as '
planning'# elog NOTICE "blah"
planning'# ';
CREATE FUNCTION
planning=# select oops (cast('duh' as varchar));
ERROR: Function oops(character varying) does not exist
Unable to identify a function that satisfies the given argument types
You may need to add explicit typecasts
Ian Harding
Programmer/Analyst II
Tacoma-Pierce County Health Department
[EMAIL PROTECTED]
Phone: (253) 798-3549
Pager: (253) 754-0002
>>> "Reuven M. Lerner" <[EMAIL PROTECTED]> 06/23/03 11:56PM >>>
Excellent -- thanks so much for your help. I just tried the function
with the right arguments, and it worked just fine.
Yet more proof of named parameters being a good thing...
Reuven
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [GENERAL] Physical Database Configuration
My solution did not involve tablespaces, but was more of a quick solution to make it easier for admins to do _some_ sort of physical configuration. The idea is that the developer could do something like 'create alternate location ALTERNATE_LOCATION_NAME for DATABASE_OBJECT_NAME at "/PATH/TO/PHYSICAL/FILE";' We would have a system table holding theses values. Then, all database commands which create a file for an object, call open_object(oid, object_name) or something to create the file object. This will first look in the new system table to see if there is a mapping for an object of this name. If so, it will create a symlink to "/PATH/TO/PHYSICAL/FILE" for the oid before opening the file. Anyway, if people are working on tablespaces, I'll defer to them. This small fix is something that I might actually have time to do, but tablespaces definitely not. Jon On Wed, 25 Jun 2003 [EMAIL PROTECTED] wrote: > > Well, correct solution is to implement tablespaces on which objects like > > databases, tables and indexes can be put. > > I've not looked at the SQL standard, but it seems to me like the order > should be: > > Databases >Tablespaces > Schemas > Objects (tables, indexes, functions, etc.) > > And it really isn't hierarchical. As I understand them (based on my > Oracle background), tablespaces, unlike schemas, do NOT create a layer > of data abstraction. That is to say, while the same table name > can exist in multiple schemas, only one instance of a given table name > within a given schema can exist, regardless of what tablespace it is in. > > That makes the tablespace a property of an object. > > Whether or not two databases can share tablespaces isn't clear to me, > though as a DBA I can think of good reasons why they probably shouldn't > do so, I'm not sure if that is an absolute. > > > I have no idea what is the status of that effort right now. You can search the > > archives or I hope this kicks a fresh discussion..:-) > > I'm game, though I'm also not ready to lead such a project, probably not > even the discussion on it. > -- > Mike Nolan > > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] lru cache replacement
On Tue, 24 Jun 2003, Tom Lane wrote: > Yutaka tanida <[EMAIL PROTECTED]> writes: > > [EMAIL PROTECTED] wrote: > >> does pgbench test with relatively large sequential scans? > > > Probably no. > > pgbench tries to avoid any seqscans at all, I believe, so it wouldn't be > very useful for testing a method that's mainly intended to prevent > seqscans from blowing out the cache. > > I tried to implement LRU-2 awhile ago, and got discouraged when I > couldn't see any performance improvement. But I was using pgbench as > the test case, and failed to think about its lack of seqscans. Yes , lru-2 will behave like LRU under 'normal' load. it will detect sequential scans and adapt to it. I think that was why you didn't see any substantial gain in cache hits. though I think ARC does a better job. LRU-2 also has logaritmic complexity overhead. The ARC guys have tested with real traces from a Db of a large insurrance company and the results were quite encouraging. (a lot of other traces where examined as well) > We could probably resurrect that code for comparison to 2Q, if anyone > can devise more interesting benchmark cases to test. As i stated before, i'm willing to implement ARC and to see how they all compare. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Week numbers and years
A minor feature request: PostgreSQL supports ISO-8601 week numbers with the syntax EXTRACT(WEEK FROM timestamp) or TO_CHAR(timestamp,'IW'). There is, however, no easy way to extract the year corresponding to the week number. Since ISO weeks may overlap year boundaries, this makes the week number functionality nearly unusable in aggregate queries. (e.g. both EXTRACT(WEEK FROM timestamp '2002-01-01') and EXTRACT(WEEK FROM timestamp '2002-12-31') returns 1.) A way to extract the year-of-week would make the extract(week from date)-functionality a lot more useful. -- Brage Førland ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] again: Bug #943: Server-Encoding from EUC_TW
Tatsuo Ishii wrote: > > > > > I reported bug #943 (I found in 7.3.2) and you checked in some change against > > > > integer overflow. > > > > Now I upgraded to 7.3.3 and I'm not happy with this. > > > > The exact error as I described is fixed, but I found new errors in conversion > > > > UTF-8 <-> EUC_TW and BIG5: > > > > > > > > Copy to table (DB has UTF-8 encoding) from file: > > > > for PGCLIENTENCODING=BIG5: > > > > WARNING: copy: line 1, LocalToUtf: could not convert (0xf9d6) BIG5 to UTF-8. > > > > Ignored > > > > WARNING: copy: line 2, LocalToUtf: could not convert (0xf9d7) BIG5 to UTF-8. > > > > Ignored > > > > WARNING: copy: line 3, LocalToUtf: could not convert (0xf9d8) BIG5 to UTF-8. > > > > Ignored > > > > WARNING: copy: line 4, LocalToUtf: could not convert (0xf9db) BIG5 to UTF-8. > > > > Ignored > > > > > > I see no problem here. The only standard conversion map I could found > > > on-line form so far (see below URL) does not include entries 0xf9d6 or > > > above. > > > > > > http://www.unicode.org/Public/UNIDATA/Unihan.txt > > > > > > I found in this file: > > U+F9D7 in line 604519 > > U+F9D8 in line 219540 > > U+F9D6...U+F9DB in lines 730707...730766. > > No. U+F9D6 means *Unicode* code point, not BIG5 code point. Ok. I have looked into my Linux box and found this in /usr/share/i18n/charmaps/BIG5.gz: % Chinese charmap for BIG5 (CP950) % version: 0.92 % Contact: Tung-Han Hsieh <[EMAIL PROTECTED]> % Yuan-Chung Cheng <[EMAIL PROTECTED]> % Distribution and use is free, even for comercial purpose. % % This charmap is converted from: % ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WINDOWS/CP950.TXT % ... There "my" characters are in. Don't you agree that it is strange that I can (for EUC_TW) copy "to" file without error but I can not copy "from" file without error? Michael > > > > > > for EUC_TW > > > > WARNING: copy: line 1, LocalToUtf: could not convert (0x8ea3c3b7) EUC_TW to > > > > UTF-8. Ignored > > > > WARNING: copy: line 2, LocalToUtf: could not convert (0x8ea3cfd0) EUC_TW to > > > > UTF-8. Ignored > > > > WARNING: copy: line 3, LocalToUtf: could not convert (0x8ea3c4ce) EUC_TW to > > > > UTF-8. Ignored > > > > WARNING: copy: line 4, LocalToUtf: could not convert (0x8ea3bdfe) EUC_TW to > > > > UTF-8. Ignored > > > > > > Hum. These seem to be CNS 11643-1993, plane 3. Currently PostgreSQL > > > supports only: > > > > > > CNS 11643-1993, plane 0 > > > CNS 11643-1993, plane 1 > > > CNS 11643-1993, plane 2 > > > CNS 11643-1993, plane 15 > > > > > > Would you like to have support for rest of CNS 11643-1993 planes: > > > > > > CNS 11643-1993, plane 3 > > > CNS 11643-1993, plane 4 > > > CNS 11643-1993, plane 5 > > > CNS 11643-1993, plane 6 > > > CNS 11643-1993, plane 7 > > > > > > support for upcoming 7.4? > > > > > > > Copy out to file from table (UTF-8 data): > > > > to BIG5 > > > > WARNING: UtfToLocal: could not convert UTF-8 (0xe7a281). Ignored > > > > WARNING: UtfToLocal: could not convert UTF-8 (0xe98ab9). Ignored > > > > WARNING: UtfToLocal: could not convert UTF-8 (0xe8a38f). Ignored > > > > WARNING: UtfToLocal: could not convert UTF-8 (0xe7b2a7). Ignored > > > > > > > > to EUC_TW is ok! > > > > > > BIG5 and EUC_TW have different code points. So this is not very strange. > > > > > > But it is very strange that I can (for EUC_TW) copy to file without error but I > > can not copy from file without error. > > > > Michael > > ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] lru cache replacement
On Tue, 24 Jun 2003 [EMAIL PROTECTED] wrote: > I was researching on cache replacement strategy as well. 2Q has one > disadvantage see this exellent paper: > http://www.almaden.ibm.com/cs/people/dmodha/#ARC see the paper > "ARC: A Self-Tuning, Low Overhead Replacement Cache" for theory and "One > Up on LRU" for implementation details. ARC requires no tuning and can > switch fast between chaging patterns. Best of all is it is resistant to a > "sequential scan" pattern. and i think it's even easier to implement then > 2q :) > > does pgbench test with relatively large sequential scans? > BTW, i'm also willing to implement ARC for pgsql if you guys also think it's a better algoritm. We will no longer have to tweak parameters like Kin, Kout. ARC also uses 2 buffers like 2q. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] join_references: variable not in subplan target lists
Peter Eisentraut <[EMAIL PROTECTED]> writes: > The cited error message appears when loading the attached file (a cut-down > version of a local development version of the information schema) I've been able to reduce the problem to this test case: drop view x1; CREATE VIEW x1 AS SELECT 1 FROM pg_type t, pg_proc p WHERE t.oid = p.prorettype AND p.pronamespace IN (SELECT n.nspname FROM pg_namespace n, pg_proc p2 WHERE n.oid = p2.pronamespace); select * from x1; While I now need to burrow into the IN-as-join code and find out where it's dropping the ball, I don't think this need stop you from making progress on the information schema. The reason the problem is appearing seems to be the implied cast that's getting introduced in the IN comparison, because pronamespace (an OID) isn't directly comparable to nspname (a NAME). (They're both getting coerced to TEXT, which once again points up my opinion that we are way too loose with implicit coercions to TEXT, but never mind that right now.) In short, the bug is being triggered only because you're comparing the wrong pair of columns, and so you'll need to change the query anyway. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Missing array support
Peter Eisentraut wrote:
It doesn't say anything specifically about multidimensional arrays, but
the grammar clearly allows declaring arrays of arrays.
::=
|
|
|
|
::=
::=
::=
ARRAY
Yeah, I noticed that after I replied. So
means something like this is valid
integer ARRAY[3] ARRAY[4] ARRAY[5]
?
Is this the same then as our syntax?
integer [3][4][5]
This also has some consequences for the cardinality function. In order to
get the cardinality of the second dimension, you'd need to call
cardinality(a[1]). (I suppose it allows different cardinalities at
various positions, so the array does not need to be an n-dimensional
rectangle.)
Hmmm. So this implies that if arr is a 2D array, we need to treat:
arr as a 2D array
arr[n] as a 1D array
arr[n][m] as a scalar
If that's true, we have a good bit of work left to do to be compliant; e.g.:
regression=# select f from z;
f
---
{{{1,1},{1,1},{1,1}},{{1,1},{1,1},{1,1}},{{1,1},{1,1},{1,1}},{{1,1},{1,1},{1,1}}}
(1 row)
regression=# select f[1][1] from z;
f
---
(1 row)
regression=# select f[1][1][1] from z;
f
---
1
(1 row)
Based on the above, "select f[1][1] from z;" ought to result in "{1,1}"?
select * from unnest(array['a','b']) as t(f1, f2) WITH ORDINALITY;
f1 | f2
+
1 | a
2 | b
The WITH ORDINALITY goes before the AS clause.
OK
The reason it is defined in terms of the LATERAL clause is that that
allows you to refer to column aliases defined in FROM items to its left.
This is the way variable arguments of function calls as table sources can
be resolved. (At least this is my interpretation. I found some examples
on the web a few months ago about this.)
Thanks for explaining that. I've never seen a LATERAL clause, and I was
wondering just what this part meant. So this applies to the discussion
we had a while back about set returning functions in the targetlist?
Joe
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Getting blocked when receinving response from a Parse
Carlos Guzman Alvarez wrote: Hello: >You must send either Flush or Sync after the Parse to force the backend >to emit its response to Parse. The assumption is that in many cases >you'll be sending Parse as part of a batch of commands, and the backend >should batch its responses to minimize the number of network packets >sent. So you have to tell it where the batch boundaries are --- thus, >Flush or Sync. See the docs concerning the difference between the two. I have the same problem some days ago with the implementation of the version 3.0 protocol in C# and now using Flush it's working quite well :) Thanks Carlos. Uhmmm, if you don't mind... are you implementing something like a data provider for Postgresql, or it is just an ad hoc program? -- Regards, Francisco Figueiredo Jr. -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi ---(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: [HACKERS] Getting blocked when receinving response from a Parse
Tom Lane wrote: "Francisco Figueiredo Jr." <[EMAIL PROTECTED]> writes: I'm implementing the 3.0 protocol version in Npgsql, a .Net Data provider for postgresql. I stopped in the first message: Parse :( I send the parse message but I don't receive the ParseComplete or the ErrorResponse. My code simply freezes while reading the byte from network stream. You must send either Flush or Sync after the Parse to force the backend to emit its response to Parse. The assumption is that in many cases you'll be sending Parse as part of a batch of commands, and the backend should batch its responses to minimize the number of network packets sent. So you have to tell it where the batch boundaries are --- thus, Flush or Sync. See the docs concerning the difference between the two. Oohh, thanks, Tom Lane! I didn't read carefully the final part of extended query where it says about the Flush message :) I didn't realize the idea of holding responses to minimize network traffic. I was thinking in the send reply style :) -- Regards, Francisco Figueiredo Jr. -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: CVS tip compile failure (was Re: [HACKERS] Missing array support)
Joe Conway wrote: FWIW, I find that if I remove "hr" and "tr" from this line in /opt/src/pgsql/src/backend/nls.mk, everything goes fine: AVAIL_LANGUAGES := cs de es hu ru sv zh_CN zh_TW Do I need to do something to get new language files? Replying to myself again ;-) I was a bit too quick to say "everything goes fine". I got several more nls related failures. Attached is the patch I used to back out the ones causing me problems. Did a "cvs add" get missed somewhere, or am I doing something wrong? Thanks, Joe Index: src/backend/nls.mk === RCS file: /opt/src/cvs/pgsql-server/src/backend/nls.mk,v retrieving revision 1.4 diff -c -r1.4 nls.mk *** src/backend/nls.mk 28 Jun 2003 22:30:59 - 1.4 --- src/backend/nls.mk 29 Jun 2003 01:09:29 - *** *** 1,6 # $Header: /opt/src/cvs/pgsql-server/src/backend/nls.mk,v 1.4 2003/06/28 22:30:59 petere Exp $ CATALOG_NAME := postgres ! AVAIL_LANGUAGES := cs de es hr hu ru sv tr zh_CN zh_TW GETTEXT_FILES := + gettext-files GETTEXT_TRIGGERS:= elog:2 postmaster_error yyerror --- 1,6 # $Header: /opt/src/cvs/pgsql-server/src/backend/nls.mk,v 1.4 2003/06/28 22:30:59 petere Exp $ CATALOG_NAME := postgres ! AVAIL_LANGUAGES := cs de es hu ru sv zh_CN zh_TW GETTEXT_FILES := + gettext-files GETTEXT_TRIGGERS:= elog:2 postmaster_error yyerror Index: src/bin/pg_controldata/nls.mk === RCS file: /opt/src/cvs/pgsql-server/src/bin/pg_controldata/nls.mk,v retrieving revision 1.4 diff -c -r1.4 nls.mk *** src/bin/pg_controldata/nls.mk 28 Jun 2003 22:31:00 - 1.4 --- src/bin/pg_controldata/nls.mk 29 Jun 2003 01:19:00 - *** *** 1,5 # $Header: /opt/src/cvs/pgsql-server/src/bin/pg_controldata/nls.mk,v 1.4 2003/06/28 22:31:00 petere Exp $ CATALOG_NAME := pg_controldata ! AVAIL_LANGUAGES := de es fr hu pt_BR ru sv zh_CN GETTEXT_FILES := pg_controldata.c GETTEXT_TRIGGERS:= _ --- 1,5 # $Header: /opt/src/cvs/pgsql-server/src/bin/pg_controldata/nls.mk,v 1.4 2003/06/28 22:31:00 petere Exp $ CATALOG_NAME := pg_controldata ! AVAIL_LANGUAGES := de es pt_BR ru sv zh_CN GETTEXT_FILES := pg_controldata.c GETTEXT_TRIGGERS:= _ Index: src/bin/pg_dump/nls.mk === RCS file: /opt/src/cvs/pgsql-server/src/bin/pg_dump/nls.mk,v retrieving revision 1.8 diff -c -r1.8 nls.mk *** src/bin/pg_dump/nls.mk 28 Jun 2003 22:31:01 - 1.8 --- src/bin/pg_dump/nls.mk 29 Jun 2003 01:16:32 - *** *** 1,6 # $Header: /opt/src/cvs/pgsql-server/src/bin/pg_dump/nls.mk,v 1.8 2003/06/28 22:31:01 petere Exp $ CATALOG_NAME := pg_dump ! AVAIL_LANGUAGES := cs de pt_BR ru sv zh_CN zh_TW GETTEXT_FILES := pg_dump.c common.c pg_backup_archiver.c pg_backup_custom.c \ pg_backup_db.c pg_backup_files.c pg_backup_null.c \ pg_backup_tar.c pg_restore.c pg_dumpall.c --- 1,6 # $Header: /opt/src/cvs/pgsql-server/src/bin/pg_dump/nls.mk,v 1.8 2003/06/28 22:31:01 petere Exp $ CATALOG_NAME := pg_dump ! AVAIL_LANGUAGES := cs de ru sv zh_CN zh_TW GETTEXT_FILES := pg_dump.c common.c pg_backup_archiver.c pg_backup_custom.c \ pg_backup_db.c pg_backup_files.c pg_backup_null.c \ pg_backup_tar.c pg_restore.c pg_dumpall.c Index: src/bin/pg_resetxlog/nls.mk === RCS file: /opt/src/cvs/pgsql-server/src/bin/pg_resetxlog/nls.mk,v retrieving revision 1.5 diff -c -r1.5 nls.mk *** src/bin/pg_resetxlog/nls.mk 28 Jun 2003 22:31:01 - 1.5 --- src/bin/pg_resetxlog/nls.mk 29 Jun 2003 01:19:26 - *** *** 1,5 # $Header: /opt/src/cvs/pgsql-server/src/bin/pg_resetxlog/nls.mk,v 1.5 2003/06/28 22:31:01 petere Exp $ CATALOG_NAME := pg_resetxlog ! AVAIL_LANGUAGES := de hu pt_BR ru sv zh_CN GETTEXT_FILES := pg_resetxlog.c GETTEXT_TRIGGERS:= _ --- 1,5 # $Header: /opt/src/cvs/pgsql-server/src/bin/pg_resetxlog/nls.mk,v 1.5 2003/06/28 22:31:01 petere Exp $ CATALOG_NAME := pg_resetxlog ! AVAIL_LANGUAGES := de pt_BR ru sv zh_CN GETTEXT_FILES := pg_resetxlog.c GETTEXT_TRIGGERS:= _ Index: src/bin/psql/nls.mk === RCS file: /opt/src/cvs/pgsql-server/src/bin/psql/nls.mk,v retrieving revision 1.8 diff -c -r1.8 nls.mk *** src/bin/psql/nls.mk 28 Jun 2003 22:31:01 - 1.8 --- src/bin/psql/nls.mk 29 Jun 2003 01:17:31 - *** *** 1,6 # $Header: /opt/src/cvs/pgsql-server/src/bin/psql/nls.mk,v 1.8 2003/06/28 22:31:01 petere Exp $ CATALOG_NAME := psql ! AVAIL_LANGUAGES := cs de fr hu ru sv zh_CN zh_TW GETTEXT_FILES := command.c common.c copy.c help.c input.c large_obj.c \
Re: CVS tip compile failure (was Re: [HACKERS] Missing array support)
Joe Conway wrote: Hmmm, I just updated to cvs tip (so I could try this), did `configure`, `make clean`, and `make all` and I'm getting this failure: make[2]: Leaving directory `/opt/src/pgsql/src/port' make -C backend all make[2]: Entering directory `/opt/src/pgsql/src/backend' msgfmt -o po/cs.mo po/cs.po msgfmt -o po/de.mo po/de.po msgfmt -o po/es.mo po/es.po make[2]: *** No rule to make target `po/hr.po', needed by `po/hr.mo'. Stop. FWIW, I find that if I remove "hr" and "tr" from this line in /opt/src/pgsql/src/backend/nls.mk, everything goes fine: AVAIL_LANGUAGES := cs de es hu ru sv zh_CN zh_TW Do I need to do something to get new language files? Joe ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
CVS tip compile failure (was Re: [HACKERS] Missing array support)
Tom Lane wrote: Peter Eisentraut <[EMAIL PROTECTED]> writes: Btw., it would be really nice if some limited form of this could get done, so I could finish the information schema views pertaining to group privileges. I'd just need a way to find out what users are in what groups. As of a few minutes ago, SELECT g.groname FROM pg_user u, pg_group g WHERE u.usesysid = ANY (g.grolist) AND u.usename = current_user; Hmmm, I just updated to cvs tip (so I could try this), did `configure`, `make clean`, and `make all` and I'm getting this failure: make[2]: Leaving directory `/opt/src/pgsql/src/port' make -C backend all make[2]: Entering directory `/opt/src/pgsql/src/backend' msgfmt -o po/cs.mo po/cs.po msgfmt -o po/de.mo po/de.po msgfmt -o po/es.mo po/es.po make[2]: *** No rule to make target `po/hr.po', needed by `po/hr.mo'. Stop. make[2]: Leaving directory `/opt/src/pgsql/src/backend' make[1]: *** [all] Error 2 make[1]: Leaving directory `/opt/src/pgsql/src' make: *** [all] Error 2 Any ideas? Joe ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Missing array support
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Btw., it would be really nice if some limited form of this could get done, > so I could finish the information schema views pertaining to group > privileges. I'd just need a way to find out what users are in what > groups. As of a few minutes ago, SELECT g.groname FROM pg_user u, pg_group g WHERE u.usesysid = ANY (g.grolist) AND u.usename = current_user; regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] pg_get_triggerdef in pg_dump
Bruce Momjian wrote: OK, added to TODO: Modify pg_get_triggerdef() to take a boolean to pretty-print, and use that as part of pg_dump along with psql Andreas, can you work on this? I like the idea of removing extra parens, and merging it into the existing code rather than into contrib makes sense. Just an announcement: I'll be sending a patch for ruleutils.c and pg_proc.h tomorrow, after I performed some further testing. pg_get_ruledef, pg_get_viewdef, pg_get_viewdef_name, pg_get_indexdef, pg_get_constraintdef and pg_get_expr get an additional parameter int4 each which controls pretty-print (0: none, 1: parentheses, 1: indentation, 3: both). I had to make several conditionals for the old parenthesing code, but I believe the functions still generate as usual if pretty-print is disabled. At the moment, I assigned oids 2504-2509 (last used was 2503 when I updated from cvs) to the additional functions, is that ok? Regards, Andreas ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] persistant psql feature suggestion
Another way is to put a little shim between the fifo and psql. Here's one I
quickly whipped up in perl (code stolen shamelessly from the perl man
pages). To run in background, invoke thus
( perl myperlfile myfifo | psql gatabase ) &
The only wrinkle I found was that I had to send the \q twice to make it
quit - I have no idea why.
andrew
--
use strict;
my $curpos;
my $fifofile = shift || usage();
$|=1;
open(FILE,$fifofile) || die $!;
for (;;)
{
for ($curpos = tell(FILE); $_ = ; $curpos = tell(FILE))
{
print $_;
}
sleep(1);
seek(FILE, $curpos, 0);
}
sub usage
{
print STDERR "usage: ",$0," fifofile\n";
exit 1;
}
- Original Message -
From: "Matthew T. O'Connor" <[EMAIL PROTECTED]>
To: "James Pye" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, June 27, 2003 1:44 PM
Subject: Re: [HACKERS] persistant psql feature suggestion
> On Fri, 2003-06-27 at 03:21, James Pye wrote:
> > Greets,
> >
> > Just a thought for a psql enhancement, afiak, it is not easily possible
for persistent connections to a database in a shell script..
> > The ability for psql to remain in the background reading from stdin and
writing to stdout until explicitly killed. More specifically, so a shell
scriptor can have "persistent" connections to the database by calling psql
once(leaving it in the bg), and redirecting stdio through a
fifo(mkfifo)(sending queries by echo > fifo, and fetching results by cat
fifo).
> > When I have tried this in the past it will read the query, execute it,
and exit when the results are cat'd from the fifo.
>
> Not sure if it's exactly what you are looking for, nor how well it's
> still maintained, but
>
> I believe there is a took out there called pgbash which is a modified
> version of bash that understands database queries natively. I think
> it's just what you are looking for.
>
> Check out: http://www.psn.co.jp/PostgreSQL/pgbash/index-e.html
>
> Looks like it was updated for 7.3
>
> Matthew
>
>
> ---(end of broadcast)---
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Missing array support
Peter Eisentraut wrote: Btw., it would be really nice if some limited form of this could get done, so I could finish the information schema views pertaining to group privileges. I'd just need a way to find out what users are in what groups. If unnest() would work for locally constant arguments, I think it could be done like SELECT g.groname FROM pg_user u, pg_group g WHERE u.usesysid IN (SELECT * FROM UNNEST((SELECT grolist FROM pg_group WHERE grosysid = g.grosysid))) AND u.usename = current_user; Or is there some other way to do this now? It isn't in CVS yet, but hopefully before Monday evening you'll be able to do this: regression=# create user u1; CREATE USER regression=# create user u2; CREATE USER regression=# create user u3; CREATE USER regression=# create group g1 with user u1,u2; CREATE GROUP regression=# create group g2 with user u1,u2,u3; CREATE GROUP regression=# \c - u1 You are now connected as new user u1. regression=> SELECT g.groname FROM pg_group g, pg_user u WHERE u.usename = current_user AND u.usesysid = ANY (g.grolist); groname - g1 g2 (2 rows) Joe ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Documentation is building again
Tom Lane writes: > Where is the build log for that build kept now? My bookmark is > http://developer.postgresql.org/docs/postgres/buildlog.html > but that doesn't seem to work. Well, I did the first build manually so the build log wasn't saved, and the next build will only happen when something changes (checks every 15 minutes), so that's when the build log should appear. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Missing array support
I wrote: > * Using an array as a table source using UNNEST, something like: > > select * from unnest(test.b); Btw., it would be really nice if some limited form of this could get done, so I could finish the information schema views pertaining to group privileges. I'd just need a way to find out what users are in what groups. If unnest() would work for locally constant arguments, I think it could be done like SELECT g.groname FROM pg_user u, pg_group g WHERE u.usesysid IN (SELECT * FROM UNNEST((SELECT grolist FROM pg_group WHERE grosysid = g.grosysid))) AND u.usename = current_user; Or is there some other way to do this now? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Documentation is building again
Peter Eisentraut <[EMAIL PROTECTED]> writes: > The documentation build on developer.postgresql.org is working again. Good. Where is the build log for that build kept now? My bookmark is http://developer.postgresql.org/docs/postgres/buildlog.html but that doesn't seem to work. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] Documentation is building again
The documentation build on developer.postgresql.org is working again. -- 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: [HACKERS] join_references: variable not in subplan target lists
Peter Eisentraut <[EMAIL PROTECTED]> writes: > On the last seven lines of the file I've marked a part that, when removed, > makes the problem disappear, which might give a hint. Besides that, I'm > clueless. Looks like I must have broken this as a side-effect of IN-subselect optimizations --- 7.3 doesn't fail. Will fix it, thanks for the test case. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Manual fixing of plpgsql_call_handler binary location
On Sat, Jun 28, 2003 at 01:25:12AM -0400, Tom Lane wrote: > Christopher Kings-Lynne <[EMAIL PROTECTED]> writes: > >>> Will I destroy things if I execute > >>> update pg_proc set probin = '/usr/lib/pgsql/plpgsql.so' where proname = > >>> 'plpgsql_call_handler'; > >> > >> Nope ... that's what I'd probably do. > > > Even better change it to '$libdir/plpgsql.so'. > > Good point. In fact the really preferred spelling (which you'd get from > a fresh 'createlang' run) is just '$libdir/plpgsql'. Both the path and > the shlib extension are better left to the backend to supply than to > hardwire in. I'm possibly more aware of this than most folk, since I > like to use HPUX which spells the shlib extension ".sl" ... Awesome -- I've questioned to myself the wisdom of having this sort of thing hardcoded, but it looks like it's already been solved. Thanks, all... -- Adam Haberlach | "When your product is stolen by thieves, you [EMAIL PROTECTED] | have a police problem. When it is stolen by http://mediariffic.com | millions of honest customers, you have a | marketing problem." - George Gilder ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] 7.2 to 7.4 upgrade issues
Rod Taylor writes: > Attached is a 7.2.4 dump (loads without error) and a 7.4 dump (loads > with error). OK, pg_dump wasn't taking into account that earlier versions didn't have grant options. I'll fix it. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [PATCHES] .pot files are unavailable (?)
Darko Prenosil writes: > Can anyone send a "Hint" to translators, so they can start on time to finish > the work before final 7.4 release ? There is no point to start translating > now, because as You said, to much messages will be changed in next two > weeks. Simple message to HACKERS would be enough. You can work on all the others, just not the "postgres" one. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] join_references: variable not in subplan target lists
The cited error message appears when loading the attached file (a cut-down version of a local development version of the information schema) and then running select * from problem_schema.element_types; On the last seven lines of the file I've marked a part that, when removed, makes the problem disappear, which might give a hint. Besides that, I'm clueless. My local tree was last updated June 28. -- Peter Eisentraut [EMAIL PROTECTED] problem_schema.sql.gz Description: application/gunzip ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Assembler error
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I am seeing this assembler warning using gcc version 2.95.3 20010315:
> > {standard input}:332: Warning: using `%si' instead of `%esi' due to `w' uffix
> > {standard input}:332: Warning: using `%ax' instead of `%eax' due to `w' suffix
>
> Bizarro. When did you start to see that? AFAIR trigger.c hasn't
> changed much recently.
>
> FWIW, I have never seen any assembler gripes using gcc 2.95.3 on HPPA.
I think it came with my upgrade to BSD/OS 4.3. I just programmed my
test script to ignore it.
--
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 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
On Sat, 28 Jun 2003, Jan Wieck wrote: > Bruce Momjian wrote: > > See my recent commit of src/tools/pgtest. It might be a good start. > > I was wondering if some existing framework, like from the Apache Xalan > package, would be a better point to start from? I hate to say it, Bruce, > but you try to reinvent the wheel by starting with a sled. Hey, I take offence at that ... up here in Canada, that sled is faster, dontcha know? especially if we throw those dogs in front of them :) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Domain casting still doesn't work right
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Here's another example of domain casting not working right: > create domain foo as varchar; > select cast(x.y as foo) from (select 'foo') as x(y); > ERROR: coerce_type: no conversion function from "unknown" to foo Not the domain's fault. You get the same error without it: regression=# select cast(x.y as varchar) from (select 'foo') as x(y); ERROR: coerce_type: no conversion function from "unknown" to character varying The problem, if it is one, is that the subselect's output column is irrevocably assigned the datatype "unknown" when we form the subselect result list. We could make this particular problem go away by coercing the subselect result to text, but that would create problems in other areas, notably UNIONs. In a UNION you need to leave the individual subselect's outputs typed as unknown as long as possible, so that they don't screw up a type assignment derived from another subselect where the column isn't an untyped literal. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Missing array support
Joe Conway writes: > I don't see anything about multidimensional arrays at all. I take it > this is SQL99 (ISO/IEC 9075-2:1999 (E))? Can you point to a more > specific paragraph? It doesn't say anything specifically about multidimensional arrays, but the grammar clearly allows declaring arrays of arrays. ::= | | | | ::= ::= ::= ARRAY This also has some consequences for the cardinality function. In order to get the cardinality of the second dimension, you'd need to call cardinality(a[1]). (I suppose it allows different cardinalities at various positions, so the array does not need to be an n-dimensional rectangle.) > > * Using an array as a table source using UNNEST, something like: > > > > select * from unnest(test.b); > > (Check the exact spec to be sure; clause 7.6.) > Whew! Anyone care to help me interpret that! At it's most basic level, I > think these are valid: > > select * from unnest(array['a','b']); > ?column? > -- > a > b > > select * from unnest(array['a','b']) WITH ORDINALITY; > ?column? | ?column? > --+-- > 1| a > 2| b Yes. > select * from unnest(array['a','b']) as t(f1, f2) WITH ORDINALITY; > f1 | f2 > + > 1 | a > 2 | b The WITH ORDINALITY goes before the AS clause. The reason it is defined in terms of the LATERAL clause is that that allows you to refer to column aliases defined in FROM items to its left. This is the way variable arguments of function calls as table sources can be resolved. (At least this is my interpretation. I found some examples on the web a few months ago about this.) -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Domain casting still doesn't work right
Here's another example of domain casting not working right: create domain foo as varchar; select cast(x.y as foo) from (select 'foo') as x(y); ERROR: coerce_type: no conversion function from "unknown" to foo -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
Bruce Momjian wrote:
See my recent commit of src/tools/pgtest. It might be a good start.
I was wondering if some existing framework, like from the Apache Xalan
package, would be a better point to start from? I hate to say it, Bruce,
but you try to reinvent the wheel by starting with a sled.
Jan
---
Gavin Sherry wrote:
On Thu, 26 Jun 2003, Kevin Brown wrote:
> The Hermit Hacker wrote:
> > On Wed, 25 Jun 2003, Kevin Brown wrote:
> >
> > > So...would it make sense to create a gborg project to which people who
> > > have written their own test suites can contribute whatever code and data
> > > they feel comfortable releasing? As a gborg project, it would be
> > > separate from the main PG distribution and would thus have no impact on
> > > the build process or anything like that. But at the same time, if there
> > > are any ideas on testing that people have had, they could be shared with
> > > others through that mechanism.
> > >
> > > And any tests which prove to be particularly useful could make their way
> > > into the PG distribution if people here wish.
> > >
> > > Of course, like anything else this could be a bad (or perhaps redundant)
> > > idea. :-)
> >
> > It doesn't sound like a bad idea ... but, it pretty much comes down to the
> > original thread: are you willing to step up and maintain such a project?
>
> Yes, I am ("how hard can it be?", he asks himself, knowing all the
> while that it's a really bad idea to be asking that question. :-).
> But I haven't the faintest idea of how or where to even start, so
> pointers would be appreciated.
Create/modify a script to automate some kind of download/sync, test and
send failure results somewhere. Make it extensible, so that other tests
can be easily added -- preferable in a self contained way. It should grow
from there.
Gavin
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
--
#==#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#== [EMAIL PROTECTED] #
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Getting blocked when receinving response from a Parse message...
Hello: >You must send either Flush or Sync after the Parse to force the backend >to emit its response to Parse. The assumption is that in many cases >you'll be sending Parse as part of a batch of commands, and the backend >should batch its responses to minimize the number of network packets >sent. So you have to tell it where the batch boundaries are --- thus, >Flush or Sync. See the docs concerning the difference between the two. I have the same problem some days ago with the implementation of the version 3.0 protocol in C# and now using Flush it's working quite well :) -- Best regards ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
