[HACKERS] updateable cursors visibility

Folks, I'd like to implement updateable cursors. I'll be working on just getting updateable cursors working for relatively simple SELECT queries (e.g. no joins, aggregates, grouping, user-defined function calls, etc.). BTW, I believe that's all the SQL spec requires, but I need to double check

Re: [HACKERS] updateable cursors visibility

On Mon, 2003-03-24 at 22:50, Hiroshi Inoue wrote: Does the SQL standard allow INSENSITIVE updatable cursors ? Hmmm... apparently not: (Subsection 14.1, Syntax Rules of DECLARE CURSOR) 11) If an updatability clause of FOR UPDATE with or without a column name list is specified, then INSENSITIVE

Re: [HACKERS] cursors: SCROLL default, error messages

On Fri, 2003-03-21 at 17:38, Tom Lane wrote: AFAICS, our CVS-tip behavior is a reasonable superset of the spec. We don't have the NO SCROLL noiseword (which was not in SQL92 anyway), but otherwise I'm happy with what's there now. Yeah, I guess there's no need to actual enforce NO SCROLL -- but

[HACKERS] cursors: SCROLL default, error messages

Folks, While doing some other cursor-related work, I noticed the following two issues: (1) Lack of NO SCROLL The SQL spec specifies that you should be able to specify NO SCROLL to DECLARE CURSOR to disallow bidirectional fetching on the cursor. We currently support the SCROLL syntax, but it had

Re: [HACKERS] cursors: SCROLL default, error messages

On Fri, 2003-03-21 at 12:12, Tom Lane wrote: Hm? As of CVS tip, SCROLL most definitely does something. Sorry -- I noticed that it doesn't actually effect whether you can do backward fetches on the cursor, which is what I should have said. (No problem here with adding the noise-word option, of

[HACKERS] cursors outside transactions

way to implement this that I'm not seeing? In particular, I'd like to know if the list would object to integrating (1) into the mainline sources (perhaps until someone gets around to doing something similar to (2), which may be never). Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID

Re: [HACKERS] cursors outside transactions

inside and outside its creating transaction. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [HACKERS] Upgrading the backend's error-message infrastructure

there are enough platforms without *either* gcc or a C99 compiler that it's worthwhile worrying about them that much (all that is at stake is some backward compatibility, anyway). Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast

Re: [HACKERS] Upgrading the backend's error-message infrastructure

just including an index of error codes in the documentation? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] Roadmap for FE/BE protocol redesign

On Mon, 2003-03-10 at 16:37, Ashley Cambrell wrote: This would also get around the problem of getting values from newly inserted rows (eg PKs) without resorting to OIDs. That's not a problem: ensure that the newly inserted row has a SERIAL column, and use currval(). Cheers, Neil -- Neil

Re: [HACKERS] regression failure in CVS HEAD

-- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [HACKERS] Cursors and backwards scans and SCROLL

straight to defaulting to 'on' in 7.4, and removing the GUC var in 7.5 Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send

Re: [HACKERS] regression failure in CVS HEAD

the actual culprit was, though... Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

[HACKERS] regression failure in CVS HEAD

is Linux 2.4, gcc 3.2. I've attached the regression.diffs file. Any ideas on what the cause might be? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC *** ./expected/triggers.out Sat Nov 23 13:13:22 2002 --- ./results/triggers.out Fri Mar 7 15:48:41 2003

Re: [HACKERS] Row level stats

). A large number seems messy. Why not -1? I also don't really like using 0 to mean enabled, but I can't think of anything better... And the default should be to disable row-level stats, naturally. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end

Re: [HACKERS] Row level stats

of installing a contrib/ module will gripe about tweaking a GUC parameter. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs

Re: [HACKERS] Updateable views...

function, etc.) If you'd like to work on getting PostgreSQL to make views updateable automatically, that would be cool -- AFAIK no one else is currently working on it. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast

Re: [HACKERS] Yet another open-source benchmark

, that shouldn't stop anyone else from doing so in the mean time :-) Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs

Re: [HACKERS] numeric datataypes as seperate library

On Wed, 2003-02-26 at 06:00, Michael Meskes wrote: And of course I don't like the idea of linking in the GPLed GNU MP library on default as this would create licensing problems. Actually, GNU MP is released under the LGPL. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID

Re: [HACKERS] REPEATED INSERT INTO ... 2nd thread

, buf); } PQputline(conn, \\.\n); PQendcopy(conn); Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] REPEATED INSERT INTO ...

improvement from this... Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])

[HACKERS] SSL warning in CVS HEAD

, info_cb); Can someone send in a patch fixing this? (I'd fix it myself, but I know nothing about OpenSSL) BTW, this is using CFLAGS='-Wall -O0', with OpenSSL 0.9.7 Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast

[HACKERS] psql regression in CVS HEAD

with libreadline4.3 Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] The last configuration file patch (I hope!) This one

On Tue, 2003-02-18 at 21:43, mlw wrote: This patch enables PostgreSQL to be far more flexible in its configuration methodology. Without weighing in on the configuration debate, one thing this patch definitely needs to do is update the documentation. Cheers, Neil -- Neil Conway [EMAIL

[HACKERS] deadlock in REINDEX

was browsing through REINDEX, trying to see if it would be possible to allow it to acquire less exclusive locks... -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can get off all lists at once

Re: [HACKERS] [INTERFACES] postgresql 7.3 versus 7.2

On Thu, 2003-02-13 at 10:42, Tom Lane wrote: I think he'll have trouble even with that :-( ... 7.3 pg_dump will try to use column-name-list syntax in its COPY commands, which the 7.2 server won't like. If you used an insert-only, data-only dump, that might work... Cheers, Neil -- Neil

Re: [HACKERS] More benchmarking of wal_buffers

at improving this, but I can't promise I'll get the time or inclination to actually do anything about it :-) Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 3: if posting/reading through Usenet

Re: [HACKERS] function to return pg_user.usesysid

= CURRENT_USER; Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] POSIX regex performance bug in 7.3 Vs. 7.2

it (of course, a fix for 7.3.3 and 7.4 is essential, IMHO). Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] POSIX regex performance bug in 7.3 Vs. 7.2

engines, notably PCRE (www.pcre.org). But switching to another engine might impose backward-compatibility problems, in terms of the details of the RE syntax. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast

Re: [HACKERS] POSIX regex performance bug in 7.3 Vs. 7.2

interpretation of the license may not be correct.) Strict Perl compatibility would be a nice feature, but right at the moment the multibyte issue is looking like the determining factor. Agreed -- ISTM that Spencer's new engine is probably the best choice. Cheers, Neil -- Neil Conway [EMAIL PROTECTED

Re: [HACKERS] POSIX regex performance bug in 7.3 Vs. 7.2

, is there (or should there be) some mechanism for increasing the size of the compiled pattern cache? Perhaps a GUC var? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can get off all lists

Re: [HACKERS] PGP signing releases

on www.postgresql.org and ftp.postgresql.org (3) Sign official releases using the PGDG private key, and provide the signatures on www.postgresql.org along with the packages themselves. If someone more experienced in the use of PGP would like to comment, please go ahead. Cheers, Neil -- Neil Conway [EMAIL

Re: [HACKERS] COUNT and Performance ...

On Sun, 2003-02-02 at 03:55, Hans-Jürgen Schönig wrote: If people want to count ALL rows of a table. The contrib stuff is pretty useful. It seems to be transaction safe. Interesting -- I didn't know about the contrib stuff. I'll update the docs patch. Cheers, Neil -- Neil Conway [EMAIL

Re: [HACKERS] Last call for 7.3.2

by the SQL command. My only reservation is that I rewrote the existing function, rather than modifying it to support the new command tags (which is better long-term, IMHO), but perhaps too invasive for a stable branch. I'm happy to let you make the call on this one... Cheers, Neil -- Neil Conway

Re: [HACKERS] COUNT and Performance ...

count(*) from big_table; count - 8388612 (1 row) Time: 26769.99 ms nconway=# SELECT tuple_count FROM pgstattuple('big_table'); tuple_count - 8388612 (1 row) Time: 24658.87 ms Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC

[HACKERS] PGP signing releases

... Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(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] Last call for 7.3.2

fixing PQcmdTuples() for some additional commands -- should that go into 7.3.2? http://archives.postgresql.org/pgsql-patches/2003-01/msg00187.php Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP

Re: [HACKERS] Interactive Documentation - how do you want it to

for comments that have no value (e.g. support requests). Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs

Re: [HACKERS] [pgsql-advocacy] Linux.conf.au 2003 Report

could dump individual schemas, then they could move their 'don't backup' tables to another schema, and just dump the other one. FYI, I submitted a patch for this a couple weeks ago (although it hasn't been applied yet...) -- it should be in 7.4 Cheers, Neil -- Neil Conway [EMAIL PROTECTED

Re: [HACKERS] Request for qualified column names

outline some behaviour that everyone can agree upon. Griping about intentionally left out features when the feature itself is not even well defined doesn't strike me as very productive. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end

Re: [HACKERS] Can we revisit the thought of PostgreSQL 7.2.4?

On Thu, 2003-01-16 at 22:47, Justin Clift wrote: Over the last few days we've had patches submitted for 7.2.3 that address a couple of things, both the WAL Recovery Bug that Tom has developed a patch for, and a couple of buffer overflows that have been widely reported. The buffer

Re: [HACKERS] Options for growth

of the license fees you'll end up paying Oracle over the years... Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs

Re: [HACKERS] Dropping OID column

On Thu, 2003-01-16 at 13:41, Rod Taylor wrote: ALTER TABLE .. SET WITHOUT OIDS; I'd prefer this, as it's more similar to the CREATE TABLE syntax. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast

[HACKERS] default to WITHOUT OIDS?

name), which would control whether a CREATE TABLE defaults to WITH or WITHOUT OIDS. In 7.4, the GUC var would default to false (so there would be no change in behavior), but in 7.5 we could switch it to true. Comments? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC

Re: [HACKERS] default to WITHOUT OIDS?

WITH OIDS, or toggling the GUC var)... Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere

Re: [HACKERS] default to WITHOUT OIDS?

table, then we're effectively leaving the decision of when to make the transition entirely within the user's hands. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe

[HACKERS] help with PL/PgSQL bug

Folks, Someone contacted me in IRC about a bug in PL/PgSQL. I've confirmed that the example SQL they sent me causes a segfault on my machine (CVS HEAD), but I've so far not had a lot of success tracking down the exact cause of the problem. Backtrace: #0 0x403ed17a in compatible_tupdesc

Re: [HACKERS] help with PL/PgSQL bug

the difference between and a NULL pointer). Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] default to WITHOUT OIDS?

On Fri, 2003-01-10 at 21:27, Christopher Kings-Lynne wrote: So what actually is the point of OIDs then? My understanding is that they're used to uniquely identify entries in system catalogs. If there's a good reason to make use of OIDs on user tables, I can't see it... Cheers, Neil -- Neil

Re: [HACKERS] default to WITHOUT OIDS?

variables and RETURNING INTO. Is it on the TODO list by any chance? IIRC, someone (Philip W?) mentioned they might implement something like this... Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP

Re: [HACKERS] EXPLAIN EXECUTE

On Thu, 2003-01-09 at 16:53, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: I notice that you can't explain stored plans, i.e., EXPLAIN EXECUTE. Might be handy to have. Yeah, that was on my to-fix list also. Heh, I too was planning to implement this. Would you like to take a

Re: [HACKERS] New Portal in Place, DNS switched ...

On Mon, 2003-01-06 at 13:26, Marc G. Fournier wrote: On Mon, 6 Jan 2003, mlw wrote: The PHP site shows adds. Ok -- but the vast majority (say, 95%) of OSS sites don't show ads. And I just checked ... so does Sourceforge ... Not on project websites, though. In any case, I'd be fine with

Re: [HACKERS] New Portal in Place, DNS switched ...

On Sat, 2003-01-04 at 19:40, Marc G. Fournier wrote: I'm just announcing here, since I'd like to see some ppl testing this out and let us know if there are any problems Why are there ads on the page? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC

Re: [HACKERS] New Portal in Place, DNS switched ...

. In fact, there are several groups that provide free hosting for OSS projects, without requiring them to display ads on their webpages (e.g. SourceForge, Savannah, etc.) Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast

Re: [HACKERS] New Portal in Place, DNS switched ...

anything for their webspace don't need to use banner ads. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] New Portal in Place, DNS switched ...

... Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(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

Re: [HACKERS] why was libpq.so's version number bumped?

Christopher Kings-Lynne said: There have been HEAPS of security fixes between 7.2 and 7.3. That's only the case if your definition of a security fix is pretty fast and loose -- as yours seems to be. Depending on your definition of security. eg. Going 'select cash_out(2);' on any 7.2 server

Re: [HACKERS] MySQL 4.1 Features

, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(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

[HACKERS] disabled, deferred triggers

of the trigger, to only add some of the firings of the trigger to the event queue. At the least with the current implementation of deferred triggers, this wouldn't be possible AFAICS. Any comments? If no has a problem with (1), I'll send in a patch implementing it to -patches. Cheers, Neil -- Neil

Re: [HACKERS] Update on replication

for related projects (unless you count something like CPAN, which is totally different) (b) GBorg is completely unknown to anyone outside the PostgreSQL community and even to many people within it... Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC

Re: [HACKERS] Update on replication

websites ]. (Not to mention that you're assuming that GBorg includes all relevant projects -- it doesn't do that now, nor is it likely to in the future.) Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast

Re: [HACKERS] Big 7.4 items

On Mon, 2002-12-16 at 13:38, Bruce Momjian wrote: OK, I just talked to Patrick on the phone, and he says Neil Conway is working on merging the code into 7.3, and adding missing pieces like logging table creation. So, it seems PITR is moving forward. Neil, can you comment on where you

Re: [HACKERS] Big 7.4 items

restrictive than PostgreSQL's: http://www.spread.org/license/ Just FYI... Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Big 7.4 items

applications would still need to be modified, but not nearly as much. Does this sound like it's worth doing? [1] -- AFAICS, the only tricky implementation detail is deciding exactly which database operations are writes. Does nextval() count, for example? Cheers, Neil -- Neil Conway [EMAIL PROTECTED

Re: [HACKERS] Big 7.4 items

in either way, it's clear that they need to be in the main CVS, in order for it to get up to speed. Why's that? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 6: Have you searched our list archives

Re: [HACKERS] bison error

1.50 or greater, due to a limitation in previous versions of Bison. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] PQnotifies() in 7.3 broken?

and 7.3 are *not* binary compatible? AFAIK that's not the case... Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister

Re: [HACKERS] 7.4 Wishlist

for better connection pooling and reusing IIRC, it's been suggested that we can implement this by passing back the transaction state as part of the FE/BE protocol -- if we're doing a protocol change for 7.4, this could be part of it. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC

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

://advocacy.postgresql.org/download/, you only have direct links to [www|ftp].postgresql.org, not any of the mirror sites. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster

Re: [HACKERS] 7.4 Wishlist

) * Rowtype assignment in PL/PgSQL Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html

Re: [HACKERS] 7.4 Wishlist

a table when the table changes? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so

Re: [HACKERS] System Tables

it might be a little out of date. Also, starting psql with -E and taking a look at the queries it uses to generate data is often useful. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe

Re: [HACKERS] record object type

On Thu, 2002-11-28 at 11:12, Steve Jackson wrote: Is there any deeper description of the record type in plpgsql? Other than in the PL/PgSQL documentation, you mean? I dunno, the code, I guess :-) What specific information are you looking for? Cheers, Neil -- Neil Conway [EMAIL PROTECTED

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

? (estimated: 19 rows, actual: 765 rows) Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL

Re: [HACKERS] next value expression

different. I submitted a patch for 7.4 that adjusts the CREATE SEQUENCE grammar to match SQL2003's CREATE SEQUENCE a little more closely, but there's a bunch more work that can be done, if we want to be fully SQL-compliant. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC

Re: [HACKERS] 7.3rc2 Test Failures

' for reading. Errno = No such file or directory (2). Looks like a problem on your end... Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

Re: [HACKERS] Error when comparing an integer to an empty string.

? Yes. I raised it as a possible point of backwards incompatibility at the time the change was made, but the consensus was that this behavior was worth getting rid of. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast

[HACKERS] xBSD shmem doc deficiency

memory paging' sysctl vaguely referred to in the docs is 'kern.ipc.shm_use_phys', right? (d) does the above sysctl also work on NetBSD and OpenBSD? Thanks in advance, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast

Re: [HACKERS] [GENERAL] Bug with sequence

defined in SQL, PL/PgSQL, etc.), I can't see a general solution (e.g. for functions defined in C). And adding random hacks to get specific functions (e.g. nextval()) to work does not strike me as a very good idea. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC

Re: [HACKERS] PREPARE and parameter types (Re: [INTERFACES] DBD::PostgreSQL)

-- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(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] PREPARE and parameter types (Re: [INTERFACES] DBD::PostgreSQL)

Tom Lane [EMAIL PROTECTED] writes: Neil Conway [EMAIL PROTECTED] writes: Why would this be needed? Couldn't we rely on the client programmer to know that '$n is of type foo', and then pass the appropriately-typed data to EXECUTE? I don't think so. You may as well ask why we waste

[HACKERS] regression test failure (CVS HEAD)

Seems like a result of Alverro's cluster patch -- looks like the patch didn't updated the expected results for the regression tests fully. Diffs below. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC *** ./expected/cluster.out Fri Nov 15 12:35:36 2002 --- ./results

Re: [HACKERS] Time to move on...

Lamar Owen [EMAIL PROTECTED] writes: On Saturday 16 November 2002 01:07, Christopher Kings-Lynne wrote: OK sorry - I was under the impression that core == commit bit... committers != core Is there any reason for this distinction? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key

[HACKERS] FOR EACH STATEMENT triggers

behavior WRT per-row INSERT triggers - specifying 'FOR EACH xxx' in CREATE TRIGGER should now be optional; if neither is specified, FOR EACH STATEMENT is the default. This is per SQL spec (SQL 200x, 11.39, 8) Comments? Cheers, Neil -- Neil Conway

Re: [HACKERS] Propose RC1 for Friday ...

Tom Lane [EMAIL PROTECTED] writes: 2. apply the patch, and ship RC1 tomorrow; I think that's the best bet. (That said, the philosophy of there's always 7.3.1 that Bruce alluded to is not one that I agree with.) Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC

Re: [HACKERS] An article mentioning PostgreSQL

-- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

Re: [HACKERS] pg_dump in 7.4

, there would be a limit to what we could divine from the function definition (e.g. we'd get practically no info about a function defined in C) -- but this might make things a little nicer, anyway. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end

Re: [HACKERS] pg_dump in 7.4

the database object itself is dropped -- i.e. you don't *want* to worry about dynamically built queries, as they are fine already Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast

Re: [HACKERS] RC1?

, but it appeared that the machine in question had some serious hardware/software problems, so I gave up. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go

Re: [HACKERS] [GENERAL] command

Shridhar Daithankar [EMAIL PROTECTED] writes: On 8 Nov 2002 at 11:03, Florian Litot wrote: yes it's good but can i have the date with each line? Err.. I don't think so. Try the log_timestamp GUC option. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC

Re: [HACKERS] [GENERAL] Database replication... - Mission Critica

assumption. Agreed. Another simple example is: INSERT INTO foo VALUES (random()); Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate

[HACKERS] PL/PgSQL buglet / doc error

--- (1 row) Should this be implemented, or should the assertion that 'RETURN is optional' be removed from the docs? Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 1: subscribe

Re: [HACKERS] PL/PgSQL buglet / doc error

Stephan Szabo [EMAIL PROTECTED] writes: On 7 Nov 2002, Neil Conway wrote: If you have declared the function to return void, then the expression can be omitted, and will be ignored in any case. I'm not sure how you translated the above to return is optional. I'd read

Re: [HACKERS] Outstanding patches

fine with it being committed as is (as you suggest), or waiting until there is more substantial work done on the topic. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9

Re: [HACKERS] CREATE TABLE/AS does not allow WITH OIDS?

source tables, or a source table defined by an SRF? Unless we can define some consistent semantics for when we use the hasoids of the source table(s), I'd say we should just add the WITH/WITHOUT OIDS syntax. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC

Re: [HACKERS] Outstanding patches

of the SQL200x sequence stuff eventually. However, if you'd rather wait for me to finish it all and then commit it at that point, that's fine with me. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast

Re: [HACKERS] [GENERAL] Database replication... - Mission Critica

architectures! That way you'd get different floating point results on each machine... IMHO, that falls into the category of: Dr., it hurts when I do this! -- Well, don't do it then :-) Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end

Re: [HACKERS] a tiny question

Luis Alberto Amigo Navarro [EMAIL PROTECTED] writes: Is there a way to set more than one shared regions? No, there isn't. Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9

Re: [HACKERS] Win32 port

a more rushed, less stable development process (and therefore more bugs). Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org

<    4   5   6   7   8   9   10   11   >