Re: [HACKERS] encoding names
> But is it really important? All Unixen that I know of handle process > text segments on a page-by-page basis; pages that aren't actually being > touched won't get swapped in. Thus, the unused maps will just sit on > disk, whether they are part of the main executable or a separate file. > I doubt there's any real performance gain to be had by making the maps > dynamically loadable. I did some testing on my Linux box (kernel 2.2) and confirmed that no performance drgration was found with unicode-conversion-enabled postgres. This proves that your theory is correct at least on Linux. Ok, I will make the unicode conversion functionality as a default if --enable-multibyte is on. -- Tatsuo Ishii ---(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] CVS access lost
fixing On Fri, 17 Aug 2001, D'Arcy J.M. Cain wrote: > I seem to have lost my CVS access to the repository. I don't know if > my password changed for some reason or what. I sent email to Marc but > no response. Can someone else check my account and let me know what > happened please. I have some PostgreSQL changes to make (including > a fix to a very nasty and sneaky bug) and I can't commit. > > Thanks. > > -- > D'Arcy J.M. Cain| Democracy is three wolves > http://www.druid.net/darcy/| and a sheep voting on > +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] CVS access lost
I seem to have lost my CVS access to the repository. I don't know if my password changed for some reason or what. I sent email to Marc but no response. Can someone else check my account and let me know what happened please. I have some PostgreSQL changes to make (including a fix to a very nasty and sneaky bug) and I can't commit. Thanks. -- D'Arcy J.M. Cain| Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] PostgreSQL 7.1.3 RPM's available for download.
Once the mirrors come up to speed, you may download the latest RPMset from: /pub/binary/v7.1.3/RPMS Please actually read the file 'README.rpm-dist' in that directory BEFORE installation. Binaries are, as before, provided for Red Hat 7.1 only at this time. Source RPM is provided, and should rebuild just fine on most any LSB-compliant RPM-based Linux. README.rpm-dist has instructions on how to rebuild, and improved instructions on building just what packages you need. Changelog from PostgreSQL-7.1.2-5PGDG RPMset: * Fri Aug 17 2001 Lamar Owen <[EMAIL PROTECTED]> - 7.1.3-1PGDG - Kerberos auth optional. - Sync with latest Rawhide RPMset. - Minor README.rpm-dist updates. - Handle stop with stale pid file. - Make packages own their directories. Kerberos-5 support is built by default. Some bugs found during some QA processing were fixed by this newer set. The new intarray code shipped with the 5PGDG set is now also optional, and not installed by default. If you want the postmaster '-i' switch behavior, please read README.rpm-dist -- the _right_ way to do this is documented there. Editing the initscript in /etc/rc.d/init.d (or /etc/init.d) is NOT recommended, as that file WILL be overwritten during an upgrade! This was probably the smoothest new build I've done in the 7.1.x series -- a testimony to the improving maturity of the 7.1.x series. One edit of the spec file, and the build just _happened_. HOWEVER, there is one known security issue in this RPMset, specifically with the postgresql-perl client, Pg.so. Due to the way RPM's are built, in conjunction with the way the Pg Makefile system works, Pg.so receives an RPATH that includes the rpm 'buildroot' in it. This is BAD. This means that any user on the box could cause Pg.so to load an arbitrary library. I am working on this, and expect to see an update once fixed. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Progress report on locale safe LIKE indexing
Peter Eisentraut wrote: > > I have so far implemented the following: > > An operator class text_binary_ops that does memcmp()-based comparison of > text data. The operators are named $<$ etc. for lack of a better idea. > That lack is further illustrated by the idea to name them "binary-<" etc., > which wouldn't get through the parser, but it doesn't need to. > > The system will use such an index for the queries in question if the > locale is not "like-safe", in the terminology of the code (I'll end up > renaming that a little). This depends on the assumption that '=' is equivalent in any locale. Is it guaranteed ? For example, ( 'a' = 'A' ) isn't allowed in any locale ? regards, Hiroshi Inoue ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] crypt and null termination
Bruce Momjian writes: > > Bruce Momjian writes: > > > > > Anyway, the patch is small so I will apply it. There is no telling what > > > OS's expect a character string there. > > > > There's a pretty good telling: Nobody ever reported a problem related to > > this. > > We have had crypts that didn't work across platforms. That's because they used different encoding algorithms. A missing null terminator has different effects, across platforms or not. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] crypt and null termination
> Bruce Momjian writes: > > > Anyway, the patch is small so I will apply it. There is no telling what > > OS's expect a character string there. > > There's a pretty good telling: Nobody ever reported a problem related to > this. We have had crypts that didn't work across platforms. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] Changelog and 7.1.3 release
Can I ask why we are mentioning the changelog for the release and not the list from the HISTORY file? Any why are we putting the changelog in the tarball anyway? Seems that could easily go on a web site. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] crypt and null termination
Bruce Momjian writes: > Anyway, the patch is small so I will apply it. There is no telling what > OS's expect a character string there. There's a pretty good telling: Nobody ever reported a problem related to this. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] User locks code
1. Just noted this in contrib/userlock/README.user_locks:
> User locks, by Massimo Dal Zotto <[EMAIL PROTECTED]>
> Copyright (C) 1999, Massimo Dal Zotto <[EMAIL PROTECTED]>
>
> This software is distributed under the GNU General Public License
> either version 2, or (at your option) any later version.
Well, anyone can put code into contrib with whatever license
he/she want but "user locks" package includes interface
functions in contrib *and* changes in our lock manager, ie
changes in backend code. I wonder if backend' part of package
is covered by the same license above? And is it good if yes?
2. Not good implementation, imho.
It's too complex (separate lock method table, etc). Much cleaner
would be implement this feature the same way as transactions
wait other transaction commit/abort: by locking objects in
pseudo table. We could get rid of offnum and lockmethod from
LOCKTAG and add
struct
{
Oid RelId;
Oid ObjId;
} userObjId;
to objId union of LOCKTAG.
This way user could lock whatever object he/she want in specified
table and note that we would be able to use table access rights to
control if user allowed to lock objects in table - missed in 1.
One could object that 1. is good because user locks never wait.
I argue that "never waiting" for lock is same bad as "always waiting".
Someday we'll have time-wait etc features for general lock method
and everybody will be happy -:)
Comments?
Vadim
P.S. I could add 2. very fast, no matter if we'll keep 1. or not.
---(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] Progress report on locale safe LIKE indexing
I have so far implemented the following: An operator class text_binary_ops that does memcmp()-based comparison of text data. The operators are named $<$ etc. for lack of a better idea. That lack is further illustrated by the idea to name them "binary-<" etc., which wouldn't get through the parser, but it doesn't need to. The system will use such an index for the queries in question if the locale is not "like-safe", in the terminology of the code (I'll end up renaming that a little). If the locale is plain C/POSIX, it will use the "normal" index. (Should it be able to use either one in that case?) Open issues: Currently, this only works on text. Before I go out and duplicate all this code and the catalog entries for varchar and bpchar, is there a Better Way? In match_special_index_operator(), the code looks up the required operators by name (<, >=). In other places we go out of our way to not attach predefined meanings to operator names. (In yet other places we do, of course.) Wouldn't it be better to test whether the candidate index is a btree and then select the operator to use from the btree strategy entries? One uglification factor here is that the comment * We cheat a little by not checking for availability of "=" ... any * index type should support "=", methinks. no longer holds. PS: I wasn't able to find or reconstruct a concrete test case for this in the archives. Naturally, I'd accept this approach on theoretical purity, but if someone remembers a real tough one, let me know. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] encoding names
Tatsuo Ishii writes: > I use Makefile.shlib to create each shared object. This way is, I > think, handy and portble. However, I need to make lots of subdirs for > each encoding conversion function. Any suggestions? Given Tom Lane's comment, I think that this would be a wasted effort. Shared objects are normally used for extensibility at runtime, not core memory savings. (This would most likely take more memory in fact, given that the code is larger and you need all the shared object handling infrastructure.) -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Dollar in identifiers
> Tom Lane writes: > > > Option 2 improves Oracle compatibility, at the price of breaking > > backwards compatibility for applications that presently use $ as part > > of multi-character operator names. (But does anyone know of any?) > > Hmm, postgresql-7.2devel_petere_privatebranch... :-( > > Well, the Euro is already allowed in identifiers, so I rest. OK, I will give my idea on this and people can make a decision. We have pulled over Oracle specific stuff when they added features to our existing code. In this case, we are addinng dollarsign to the identifiers just for compability. No one is saying, "Gee, I like to see dollarsigns in my tablenames, and I can't do that." They want it only for compatibility. Now, I know we have accepted compatibility stuff when it was easy to do. It is just that changing the identifiers we accept seems pretty major to me. However, if others think it isn't a big deal, I can go along with it. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] PostgreSQL v7.1.3 bundled and uploaded to central FTP Server
Morning all ... PostgreSQL v7.1.3 has just been bundled and uploaded onto the central FTP server, with mirrors to follow over the next several hours ... The ChangeLog file is/will be viewable on the mirrors under: /pub/latest/README.ChangeLog Being a purely bug fix release, there is no need to do a dump/restore to upgrade to this release. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Re: CREATEDB Where ??
Peter Moscatt <[EMAIL PROTECTED]> wrote in message
news:<4x9f7.126086$[EMAIL PROTECTED]>...
> I am pretty new to PostgreSQL so please bare with me :-)
>
> When issuing the CREATEDB MyDb then creating some tables with CREATE
> TABLE, I then go back and do a search for the file I have just created
> (MyDb) but can't find the physical file.
>
> Does one actually exist ??
>
> Pete
Sure it does. The problem you are having is that since the
implementation of TOAST in PG 7.1, all of the db and table names are
represented by numbers in the physical file system
(usr/local/pgsql/data/base). So if you tried to do an 'ls' or 'find'
for the name of your database, it probably wouldn't show up. However,
just do a 'psql {db_name}' (where {db_name} is the name of your
database) and you'll see that everything is kosher.
To translate the oid numbers to their respective names, use the
oid2name function found in the /contrib under your Postgres source
code.
-Tony
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Fw: [PATCHES] Re: [HACKERS] Re: WIN32 errno patch
As usual i didn't cc the list :) Magnus - Original Message - From: "Magnus Naeslund(f)" <[EMAIL PROTECTED]> To: "Tom Lane" <[EMAIL PROTECTED]> Sent: Friday, August 17, 2001 6:55 PM Subject: Re: [PATCHES] Re: [HACKERS] Re: WIN32 errno patch > From: "Tom Lane" <[EMAIL PROTECTED]> > [snip] > > FWIW, Magnus says this works: > > > > #define SOCK_STRERROR my_sock_strerror > > > [snip] > > > > > > Anyone have any objections to it? > > > > regards, tom lane > > > > I can make that patch if you'd like, but i need to know what i should be > working on (right from CVS?). > In what context is it? (the libpq lib maybe). > And how to test it :) > > I can do the legwork. > > Magnus > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Programmer/Networker [|] Magnus Naeslund > PGP Key: http://www.genline.nu/mag_pgp.txt > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: Rough idea for supporting "sequencename.nextval" syntax
"Ross J. Reedstrom" <[EMAIL PROTECTED]> writes:
> Tom, would it make sense to use this new type in the system tables where
> pg_class oids currently are used, such as pg_attribute.attrelid ?
Probably. We already use regproc where pg_proc OIDs are used --- not
completely consistently IIRC, but it'd be good to be more consistent.
> Then, one could do:
> select attname from pg_attributes where attrelid = 'mytablename';
> If the appropriate type conversions where in place. (I just tried this
> with pg_aggregate, looking for aggregates that use a particular operator,
> and failed, since text() yields the oid, rather than
> the name.)
Good thought. At the moment an explicit cast is needed for regproc,
and probably the same would be true of regclass unless we did some
further hacking:
regression=# select * from pg_aggregate where aggfinalfn = 'interval_avg';
ERROR: oidin: error in "interval_avg": can't parse "interval_avg"
regression=# select * from pg_aggregate where aggfinalfn = 'interval_avg'::regproc;
aggname | aggowner | aggtransfn | aggfinalfn | aggbasetype | aggtranstype |
aggfinaltype | agginitval
-+--++--+-+--+--+-
avg | 256 | interval_accum | interval_avg |1186 | 1187 |
1186 | {0 second,0 second}
(1 row)
I think the reason the literal is resolved as OID not regproc is that we
are using the OID equality operator here (relying on binary equivalence
of OID and regproc). I don't much want to invent a whole set of regproc
and regclass operators to avoid that. Perhaps the unknown-type
resolution rules could be fine-tuned somehow to resolve as the type of
the other operand, rather than the declared input type of the operator,
in cases like this. (Thomas, any thoughts about that?)
Looking at this, I can't help wondering about "regtype" too ...
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Rough idea for supporting "sequencename.nextval" syntax
On Thu, Aug 16, 2001 at 10:36:49PM -0400, Tom Lane wrote: > I said: > > Suppose that we invent a new datatype "regclass", similar to regproc: > > it's actually an OID, but it has the additional implication that it is > > the OID of a pg_class row, and the I/O operations for the type try to > > accept or print a class name not just a numeric OID. Tom, would it make sense to use this new type in the system tables where pg_class oids currently are used, such as pg_attribute.attrelid ? Then, one could do: select attname from pg_attributes where attrelid = 'mytablename'; If the appropriate type conversions where in place. (I just tried this with pg_aggregate, looking for aggregates that use a particular operator, and failed, since text() yields the oid, rather than the name.) This would essentially special case the join of two system tables. Hmm, sounds like a step down the trail to not needing user visible oids for system tables, even. > This is starting to seem less like a kluge and more like a real > feature... Ross ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Dollar in identifiers
Tom Lane writes: > Option 2 improves Oracle compatibility, at the price of breaking > backwards compatibility for applications that presently use $ as part > of multi-character operator names. (But does anyone know of any?) Hmm, postgresql-7.2devel_petere_privatebranch... :-( Well, the Euro is already allowed in identifiers, so I rest. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(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] Dollar in identifiers
> Bruce Momjian <[EMAIL PROTECTED]> writes: > > Sure, if you want to remove it from operators, that is fine, but adding > > it to identifiers seems weird seeing as only one person wants it and it > > isn't standard. > > ?? I don't see any value in not using $ for *either* purpose. That > breaks backwards compatibility for hardly any gain at all. OK, if you think it should be kept for backward compatibility, then go ahead and keep it, but I see little value in adding it to identifiers unless it is part of an Oracle-compatibility module or at least an Oracle-compatibility #define. How many user-defined $ operators do you think are out there? I doubt very many. I would be surprised to find even one. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Dollar in identifiers
Bruce Momjian <[EMAIL PROTECTED]> writes: > Sure, if you want to remove it from operators, that is fine, but adding > it to identifiers seems weird seeing as only one person wants it and it > isn't standard. ?? I don't see any value in not using $ for *either* purpose. That breaks backwards compatibility for hardly any gain at all. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Dollar in identifiers
> In fact, with $-as-identifier we'd have this useful property: given a > lexically-recognizable identifier, substitution of a parameter token > for the identifier does not require insertion of any whitespace to > keep the parameter lexically recognizable. Some of you will recall > plpgsql bugs associated with the fact that the current lexer behavior > does not have this property. (The other direction doesn't work 100%, > for example: "select $1from" is lexable, "select foofrom" isn't. But > that direction is much less interesting in practice.) > > In short, $-as-identifier makes the lexer behavior noticeably cleaner > than it is now. > > I started out firmly in the "keep $ an operator character" camp. But > after thinking this through I'm sitting on the fence: both options seem > about equally attractive to me. Sure, if you want to remove it from operators, that is fine, but adding it to identifiers seems weird seeing as only one person wants it and it isn't standard. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(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] Dollar in identifiers
I've been thinking some more about this dollar-sign business. There are a couple of points that haven't been made yet. If you'll allow me to recap: It seems like there are two reasonable paths we could take: 1. Keep $ as an operator character. If we go this way, I think we should allow a single $ as an operator name too (by removing $ from the set of "self" characters in scan.l, so that it lexes as an Op). 2. Make $ an identifier character. Remove it from the set of allowed operator characters, and instead allow it as second-or-later character in identifiers. (It cannot be allowed as first character, else it's totally ambiguous whether $12 is meant to be a parameter or identifier.) Option 2 improves Oracle compatibility, at the price of breaking backwards compatibility for applications that presently use $ as part of multi-character operator names. (But does anyone know of any?) An important thing to think about here is the effects on lexing of parameter symbols ($digits). Option 1 does not complicate parameter lexing; $digits will still be read as a parameter since it's a longer token than could be formed by taking the $ as an Op. However, this option doesn't make things any better either: in particular, we still have the lexing ambiguity of multicharacter operator vs. parameter. "x+$12" will be read as x +$ 12, though more likely x + $12 was meant. With $-as-identifier, it'd no longer be possible for adjacent operators and parameters to be confused. Instead we have a new ambiguity with adjacent parameters and identifiers/keywords. Presently "select$1from" is read as SELECT param FROM, but with $-as-identifier it'd be read as a single identifier. But the interesting point is that this'd make parameters work a lot more like identifiers. People don't expect to be able to write identifiers adjacent to other identifiers with no whitespace. They do expect to be able to write them adjacent to operators. In fact, with $-as-identifier we'd have this useful property: given a lexically-recognizable identifier, substitution of a parameter token for the identifier does not require insertion of any whitespace to keep the parameter lexically recognizable. Some of you will recall plpgsql bugs associated with the fact that the current lexer behavior does not have this property. (The other direction doesn't work 100%, for example: "select $1from" is lexable, "select foofrom" isn't. But that direction is much less interesting in practice.) In short, $-as-identifier makes the lexer behavior noticeably cleaner than it is now. I started out firmly in the "keep $ an operator character" camp. But after thinking this through I'm sitting on the fence: both options seem about equally attractive to me. Comments? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
