Re: [HACKERS] Locale-dependent case conversion in {identifier}

By no means I would try to convince that your reading of the SQL standards is wrong. What I am trying to tell is that Turkish alphabet is broken beyond repair. And since there is absolutely no way to change our alphabet, we may can code a workaround in the code. So i do not claim that your code is

Re: [HACKERS] 7.4 Wishlist

On Fri, Nov 29, 2002 at 10:51:26AM -0800, Christopher Kings-Lynne wrote: > Just out of interest, if someone was going to pay you to hack on Postgres > for 6 months, what would you like to code for 7.4? Well, nobody is paying me, but I want to - fix the btree problem leaking unused pages (I thin

Re: [HACKERS] Planning for improved versions of IN/NOT IN

Mike Mascari <[EMAIL PROTECTED]> writes: > I curious if any of the rewriting of EXISTS and NOT EXISTS would > address the problem described by Date: > http://www.firstsql.com/iexist.htm We are not here to redefine the SQL spec ... and especially not to eliminate its concept of NULL, which is wha

Re: [HACKERS] Planning for improved versions of IN/NOT IN

Joe Conway wrote: Tom Lane wrote: I've been thinking about how to improve the performance of queries using "WHERE x IN (subselect)" and "WHERE x NOT IN (subselect)". How about starting with a rule-based method to make the choice? 1. If uncorrelated: use hash-based approach - ISTM this might a

Re: [HACKERS] Planning for improved versions of IN/NOT IN

Tom Lane wrote: I've been thinking about how to improve the performance of queries using "WHERE x IN (subselect)" and "WHERE x NOT IN (subselect)". In the existing implementation, the subquery result is rescanned to look for a match to x each time the WHERE clause is executed; this essentially ma

Re: [HACKERS] Postgres 7.3 announcement on postgresql.org

Vince Vielhaber wrote: > Yes it would. But while on the subject, why did you only mention it's > availability being on the advocacy site? *We* mentioned it's availability being on the Advocacy site, because it gives people a single place to go that has both PostgreSQL itself *and* a site that's

Re: [HACKERS] Locale-dependent case conversion in {identifier}

"Nicolai Tufar" <[EMAIL PROTECTED]> writes: > So I have changed lower-case conversion code in scan.l to make it purely > ASCII-based. > as in keywords.c. Mini-patch is given below. Rather than offering a patch, you need to convince us why our reading of the SQL standard is wrong. ("Oracle does it

Re: [HACKERS] Postgres 7.3 announcement on postgresql.org

On Sat, 30 Nov 2002, Justin Clift wrote: > Vince Vielhaber wrote: > > > > On Fri, 29 Nov 2002, Bruce Momjian wrote: > > > > > > > > FYI, Vince, I started reading all my email (using elm) in a special 120 > > > column wide, 38 row xterm. There was just too much detail in those > > > subjects i was

[HACKERS] Archive links slightly redundant

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The archives for the following mailing lists appear to have two identical links to November 2002: admin advocacy announce bugs cygwin Here's one of them: http://archives.postgresql.org/pgsql-announce/ Greg Sabino Mullane [EMAIL PROTECTED] PGP K

Re: [HACKERS] Postgres 7.3 announcement on postgresql.org

Vince Vielhaber wrote: > > On Fri, 29 Nov 2002, Bruce Momjian wrote: > > > > > FYI, Vince, I started reading all my email (using elm) in a special 120 > > column wide, 38 row xterm. There was just too much detail in those > > subjects i was missing. > > Doesn't do me much good if too often I do

Re: [HACKERS] Postgres 7.3 announcement on postgresql.org

On Fri, 29 Nov 2002, Bruce Momjian wrote: > > FYI, Vince, I started reading all my email (using elm) in a special 120 > column wide, 38 row xterm. There was just too much detail in those > subjects i was missing. Doesn't do me much good if too often I don't have the luxury of a large screen 'cuz

Re: [HACKERS] Postgres 7.3 announcement on postgresql.org

On 29 Nov 2002, Ryan Mahoney wrote: > Scroll down and read the rest of, it's an excellent announcement! If > the website and mirrors made mention of the release (as of 8:19PM CST > they don't!) and the message was sent to all the mailing lists, there > would probably be less confusion. When I re

Re: [HACKERS] Postgres 7.3 announcement on postgresql.org

FYI, Vince, I started reading all my email (using elm) in a special 120 column wide, 38 row xterm. There was just too much detail in those subjects i was missing. --- Vince Vielhaber wrote: > On Fri, 29 Nov 2002, Christophe

Re: [HACKERS] Postgres 7.3 announcement on postgresql.org

> When I did find it, this is what I saw when I opened it: > - > > > For Immediate Release November 28th, 2002 > > Contacts: > Justin Clift > [EMAIL PROTECTED] > +61.3 9363 1313 (Australia) > >

Re: [HACKERS] Postgres 7.3 announcement on postgresql.org

On Fri, 29 Nov 2002, Christopher Kings-Lynne wrote: > > Glad you liked it. But that doesn't change the fact that it obscured the > > release to the point that many people didn't even know it was released. > > I found out by folks complaining about broken links. > > Hrm - the subject said it all,

Re: [HACKERS] Postgres 7.3 announcement on postgresql.org

> Glad you liked it. But that doesn't change the fact that it obscured the > release to the point that many people didn't even know it was released. > I found out by folks complaining about broken links. Hrm - the subject said it all, plus what about the first 2 paragraphs? " PostgreSQL Global D

Re: [HACKERS] Postgres 7.3 announcement on postgresql.org

On Fri, 29 Nov 2002, Christopher Kings-Lynne wrote: > > > Marc claimed he'd put out the announcement on pgsql-announce, but that > > > copy of the message never arrived here (it did show up on pgsql-general > > > though). Evidently you and Vince never got it either ... > > > > After alot of searc

Re: [HACKERS] 7.4 Wishlist

At 05:33 PM 29/11/2002 -0800, Christopher Kings-Lynne wrote: Hmmm. I could have sworn that someone (Neil?) already did that? Not AFAICT - at least based on looking at the manual. I'll check the code. Philip Warner

[HACKERS] Locale-dependent case conversion in {identifier}

Comment in {identifier} section in src/backend/parser/scan.l states: [...] * Note: here we use a locale-dependent case conversion, * which seems appropriate under SQL99 rules, whereas * the keyword comparison was NOT locale-depen

Re: [HACKERS] 7.4 Wishlist

> > > - COPY TO/FROM with a list of columns (maybe we have it?) - it's useful > >for > > > making metadata changes then reloading data (Inserts are much slower). > > > >We do already have it in 7.3: > > Excellent. Then I just need to add support in pg_dump. Hmmm. I could have sworn that someone (

Re: [HACKERS] 7.4 Wishlist

At 04:56 PM 29/11/2002 -0800, Christopher Kings-Lynne wrote: > > - COPY TO/FROM with a list of columns (maybe we have it?) - it's useful for > making metadata changes then reloading data (Inserts are much slower). We do already have it in 7.3: Excellent. Then I just need to add support in pg_du

Re: [HACKERS] 7.4 Wishlist

> I've actually started working on pg_dump in the background, but if you want > to do it let me know. Nah - you can do it! I don't have much time to code Postgres as it is. I'll stick to working on making ADD COLUMN compliant. > In terms of things I would like to see: > > - background/integrated

Re: [HACKERS] Postgres 7.3 announcement on postgresql.org

> > Marc claimed he'd put out the announcement on pgsql-announce, but that > > copy of the message never arrived here (it did show up on pgsql-general > > though). Evidently you and Vince never got it either ... > > After alot of searching I did find it. It wasn't exactly what one would > expect

Re: [HACKERS] 7.4 Wishlist

At 10:51 AM 29/11/2002 -0800, Christopher Kings-Lynne wrote: * pg_dump dependency ordering I've actually started working on pg_dump in the background, but if you want to do it let me know. In terms of things I would like to see: - background/integrated vacuum (not just an overwriting storage

Re: [HACKERS] Postgres 7.3 announcement on postgresql.org

On Fri, 29 Nov 2002, Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > Has there been a release? It certainly hasn't been announced in the usual > > places that I monitor. > > Marc claimed he'd put out the announcement on pgsql-announce, but that > copy of the message never arriv

Re: [HACKERS] Tightening selection of default sort/group operators

Peter Eisentraut <[EMAIL PROTECTED]> writes: > My first thought is that this seems to be an awefully backwards way to > define operator semantic metadata. Why? The property we are interested in is that two operators '<' and '=' will work for grouping --- ie, if you order by '<' and then combine a

Re: [HACKERS] Postgres 7.3 announcement on postgresql.org

> Peter Eisentraut <[EMAIL PROTECTED]> writes: > > Has there been a release? It certainly hasn't been announced in the usual > > places that I monitor. > > Marc claimed he'd put out the announcement on pgsql-announce, but that > copy of the message never arrived here (it did show up on pgsql-gener

Re: [HACKERS] Postgres 7.3 announcement on postgresql.org

Peter Eisentraut <[EMAIL PROTECTED]> writes: > Has there been a release? It certainly hasn't been announced in the usual > places that I monitor. Marc claimed he'd put out the announcement on pgsql-announce, but that copy of the message never arrived here (it did show up on pgsql-general though).

Re: [HACKERS] Postgres 7.3 announcement on postgresql.org

Christopher Kings-Lynne writes: > It has been announced on the announce mailing list and in the eweek > article... It's downloadable from the advocacy site... Yeah, that'll let the world know. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--

Re: [HACKERS] Tightening selection of default sort/group operators

Tom Lane writes: > What I'm thinking of doing instead is always looking up the "=" operator > by name, and accepting this as actually being equality if it is marked > mergejoinable or hashjoinable or has eqsel() as its restriction > selectivity estimator (oprrest). If we are looking for a "<" ope

Re: [HACKERS] Postgres 7.3 announcement on postgresql.org

- Original Message - From: "Peter Eisentraut" <[EMAIL PROTECTED]> To: "Christopher Kings-Lynne" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, November 29, 2002 4:16 PM Subject: Re: [HACKERS] Postgres 7.3 announcement on postgresql.org > Christopher Kings-Lynne writes: > > > T

Re: [HACKERS] doc/src/Makefile annoyance

Tom Lane writes: > Anyone know why the install target in doc/src/Makefile is coded like > this: > > install: > $(MAKE) all > (mv -f *.$(ZIPSUFFIX) ..) Legacy. Note also that "install" doesn't do here what it usually does. Feel free to make adjustments. -- Peter Eisentraut [EMAIL

Re: [HACKERS] Postgres 7.3 announcement on postgresql.org

Christopher Kings-Lynne writes: > There isn't one! Has there been a release? It certainly hasn't been announced in the usual places that I monitor. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our l

Re: [HACKERS] 7.4 Wishlist

Wow Hannu - your list puts mine to shame! > "Application server support" > > * better XML integration > > - XML(*) aggregate function returning XML representation of subquery > > - XML input/output to/from tables > > - XML searchable/indexable in fields) I've ha

Re: [HACKERS] 7.4 Wishlist

Christopher Kings-Lynne wrote: Hi guys, Just out of interest, if someone was going to pay you to hack on Postgres for 6 months, what would you like to code for 7.4? Replication. Replication. Replication. Replication. Replication. Replication. Replication. Replication. Replication. Replication.

Re: [HACKERS] Thinking about IN/EXISTS optimization

On Fri, 2002-11-29 at 13:22, Tom Lane wrote: > Mike Benoit <[EMAIL PROTECTED]> writes: > > I'm just curious, will your proposed in/exists optimizations help for > > queries like: > > > db=# explain delete from dns_expired_domains where domain_id in (select > > domain_id from dns_expired_domains gr

Re: [HACKERS] 7.4 Wishlist

pg_dump, our upgrade process is painful enough having to do a dump, reload. I think we should be able to guarantee (or at least let much closer to it) that the process works in all cases. Personally pg_upgrade would be even nicer. - Original Message - From: "Christopher Kings-Lynne" <[EMA

Re: [HACKERS] 7.4 Wishlist

Christopher Kings-Lynne kirjutas R, 29.11.2002 kell 23:51: > Hi guys, > > Just out of interest, if someone was going to pay you to hack on Postgres > for 6 months, what would you like to code for 7.4? > > My ones are: > > * Compliant ADD COLUMN > * Integrated full text indexes > * pg_dump depend

Re: [HACKERS] Thinking about IN/EXISTS optimization

Mike Benoit <[EMAIL PROTECTED]> writes: > I'm just curious, will your proposed in/exists optimizations help for > queries like: > db=# explain delete from dns_expired_domains where domain_id in (select > domain_id from dns_expired_domains group by domain_id having count(*)=14 > ); Probably, but I

Re: [HACKERS] Postgres 7.3 announcement on postgresql.org

Christopher Kings-Lynne wrote: There isn't one! Chris No kidding. I propose changes to the following pages: : Prominent mention of the latest stable and unstable releases (just stable now, of course). But since this seems to be kind of a repeat of the news pa

Re: [HACKERS] Thinking about IN/EXISTS optimization

Tom, I'm just curious, will your proposed in/exists optimizations help for queries like: db=# explain delete from dns_expired_domains where domain_id in (select domain_id from dns_expired_domains group by domain_id having count(*)=14 ); NOTICE: QUERY PLAN: Seq Scan on dns_expired_domains (cost

Re: [HACKERS] nested transactions

I am concerned this is getting beyond my capabilities for 7.4 --- anyone want to help? --- Tom Lane wrote: > Manfred Koizar <[EMAIL PROTECTED]> writes: > > Maybe. The whole point of my approach is: If we can limit the acti

Re: [HACKERS] nested transactions

Manfred Koizar <[EMAIL PROTECTED]> writes: > Maybe. The whole point of my approach is: If we can limit the active > range of transactions requiring parent xid lookups to a small fraction > of the range needing pg_clog lookups, then it makes sense to store > status bits and parent xids in differen

Re: [HACKERS] nested transactions

Manfred Koizar wrote: > On Fri, 29 Nov 2002 13:33:28 -0500, Tom Lane <[EMAIL PROTECTED]> > wrote: > >Unfortunately this discussion is wrong. User-level visibility checks > >will usually have to fetch the parentxid in case 01 as well, because > >even if the parent is committed, it might not be visi

[HACKERS] Postgres 7.3 announcement on postgresql.org

There isn't one! Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [HACKERS] nested transactions

On Fri, 29 Nov 2002 13:33:28 -0500, Tom Lane <[EMAIL PROTECTED]> wrote: >Unfortunately this discussion is wrong. User-level visibility checks >will usually have to fetch the parentxid in case 01 as well, because >even if the parent is committed, it might not be visible in our >snapshot. Or we don

[HACKERS] eWeek Article

Looks like the eWeek article has been published: http://www.eweek.com/article2/0,3959,732789,00.asp Sorry for sounding like such a dork :) Chris ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscri

[HACKERS] 7.4 Wishlist

Hi guys, Just out of interest, if someone was going to pay you to hack on Postgres for 6 months, what would you like to code for 7.4? My ones are: * Compliant ADD COLUMN * Integrated full text indexes * pg_dump dependency ordering What would you guys do? Even if it isn't feasible right now...

Re: [HACKERS] nested transactions

Manfred Koizar <[EMAIL PROTECTED]> writes: > Visibility check by other transactions: If a tuple is visited and its > XMIN/XMAX_IS_COMMITTED/ABORTED flags are not yet set, pg_clog has to > be consulted to find out the status of the inserting/deleting > transaction xid. If pg_clog[xid] is ... >

Re: [HACKERS] Aren't lseg_eq and lseg_ne broken?

Tom Lane wrote: > By chance I just noticed that lseg equality is coded as > > Datum > lseg_eq(PG_FUNCTION_ARGS) > { > LSEG *l1 = PG_GETARG_LSEG_P(0); > LSEG *l2 = PG_GETARG_LSEG_P(1); > > PG_RETURN_BOOL(FPeq(l1->p[0].x, l2->p[0].x) && >FPeq(l1->p[1].y,

[HACKERS] Aren't lseg_eq and lseg_ne broken?

By chance I just noticed that lseg equality is coded as Datum lseg_eq(PG_FUNCTION_ARGS) { LSEG *l1 = PG_GETARG_LSEG_P(0); LSEG *l2 = PG_GETARG_LSEG_P(1); PG_RETURN_BOOL(FPeq(l1->p[0].x, l2->p[0].x) && FPeq(l1->p[1].y, l2->p[1].y) && FP

[HACKERS] Tightening selection of default sort/group operators

I noticed that the system is really pretty shaky about how it chooses the datatype-specific operators to implement sorting and grouping. In the GROUP BY case, for example, the parser looks up an operator named '<' for the column datatype, and then sometime later the executor looks up an operator na

Re: [HACKERS] nested transactions

On Thu, 28 Nov 2002 12:59:21 -0500 (EST), Bruce Momjian <[EMAIL PROTECTED]> wrote: >Yes, locking is one possible solution, but no one likes that. One hack >lock idea would be to create a subtransaction-only lock, [...] > >> [...] without >> having to touch the xids in the tuple headers. > >Yes, yo

Re: [HACKERS] Query performance. 7.2.3 Vs. 7.3

At 09:58 PM 11/28/02 -0500, you wrote: >Hm. Are we sure that both versions were built with the same >optimization level, etc? (My private bet is that Wade's 7.2 didn't >have multibyte or locale support --- but that's a long shot when we >don't know the datatypes of the columns being joined on...)

Re: [HACKERS] How to compile postgres source code in VC++

You can't, at least not until 7.4. You can compile the interfaces like libpq and the binary psql. See win32.mak for that. --- Prasanna Phadke wrote: > > Can anybody explain me, how to compile postgres source code in VC++.

Re: [HACKERS] nested transactions

Manfred Koizar wrote: > One more argument for pg_subtrans being visible to all backends: If > an UPDATE is about to change a tuple touched by another active > transaction, it waits for the other transaction to commit or abort. > We must always wait for the main transaction, not the subtrans. This

Re: [HACKERS] nested transactions

"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes: > Right now AVD only performs vacuum analyze on specific tables as it deems they > need it, it does not perform vacuum on entire databases at any point yet. See http://www.ca.postgresql.org/users-lounge/docs/7.2/postgres/routine-vacuuming.html Ho

Re: [HACKERS] nested transactions

Manfred Koizar <[EMAIL PROTECTED]> writes: > 1) If your site/instance/application/whatever... does not use nested > transactions or does use them only occasionally, you don't have to pay > the additional I/O cost. As I already said to Bruce, designing this facility on the assumption that it will b

Re: [HACKERS] Auto Vacuum Daemon (again...)

On 29 Nov 2002 at 7:59, Matthew T. O'Connor wrote: > On Thursday 28 November 2002 23:26, Shridhar Daithankar wrote: > > On 28 Nov 2002 at 10:45, Tom Lane wrote: > > > This is almost certainly a bad idea. vacuum is not very > > > processor-intensive, but it is disk-intensive. Multiple vacuums run

Re: [HACKERS] nested transactions

On Friday 29 November 2002 00:56, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> But we already have a recycling mechanism for pg_clog. AFAICS, > >> creating a parallel log file with a separate recycling mechanism is > >> a study in wasted effort. > > > > But

Re: [HACKERS] Auto Vacuum Daemon (again...)

On Thursday 28 November 2002 23:26, Shridhar Daithankar wrote: > On 28 Nov 2002 at 10:45, Tom Lane wrote: > > "Matthew T. O'Connor" <[EMAIL PROTECTED]> writes: > > > interesting thought. I think this boils down to how many knobs do we > > > need to put on this system. It might make sense to say al

Re: [HACKERS] Is current_user a function ?

On 28 Nov 2002 11:34:49 -0500 Rod Taylor <[EMAIL PROTECTED]> wrote: > Force the system to use it as a function. > select "current_user"(); On Thu, 28 Nov 2002 17:20:59 -0500 Tom Lane <[EMAIL PROTECTED]> wrote: > > As for some current_*** functions, "select current_user;" seems to > > work, but

Re: [HACKERS] nested transactions

On Thu, 28 Nov 2002 21:46:09 -0500, Tom Lane <[EMAIL PROTECTED]> wrote: >Manfred suggested a separate log file ("pg_subclog" or some such) but >I really don't see any operational advantage to that. You still end up >with 4 bytes per transaction, you're just assuming that putting them >in a differe