Re: [HACKERS] to_char() and negative intervals
On Fri, Aug 13, 2004 at 12:24:28PM -0400, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Someone on IRC just reported this to_char() failure with negative > > intervals: > > I think Karel wanted to remove to_char(interval) altogether. Yes, the notice about it is already in 7.4 docs. Maybe we can remove it in 7.5/8.0. Comments? Karel -- Karel Zak <[EMAIL PROTECTED]> http://home.zf.jcu.cz/~zakkr/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] plpgsql NULL statement (was Re: [GENERAL] Postgres
Dennis Bjorklund <[EMAIL PROTECTED]> writes: > Is NULL above an empty statement in oracle or is it a normal expression It's an actual empty statement. > (the normal NULL value) so that the above is a shorthand for >WHEN OTHERS THEN SELECT NULL; Even if it were, the point here is to accept standard Oracle coding without any translation of that sort. 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] to_char() and negative intervals
Karel Zak wrote: > On Fri, Aug 13, 2004 at 12:24:28PM -0400, Tom Lane wrote: > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > Someone on IRC just reported this to_char() failure with negative > > > intervals: > > > > I think Karel wanted to remove to_char(interval) altogether. > > Yes, the notice about it is already in 7.4 docs. Maybe we can remove > it in 7.5/8.0. Comments? I don't see how we can remove it in 8.0 unless we require an initdb. What we could do is to throw an error/warning in the code and remove it completely in 8.1. -- 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 8: explain analyze is your friend
[HACKERS] COPY with column headings
Someone just asked about a COPY capability to supply the column headings as the first line of the copy statement. Do we want to support something like that? Does anyone else want such functionality? -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] COPY with column headings
Bruce Momjian <[EMAIL PROTECTED]> writes: > Someone just asked about a COPY capability to supply the column headings > as the first line of the copy statement. Do we want to support > something like that? No. Tell him to use SELECT. (Such a capability would be a permanent hazard, because any time you tried to import with the opposite setting from what you'd exported, you'd either get a failure, or bad data, or silent loss of the first line of real data.) regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] COPY with column headings
On Mon, Aug 16, 2004 at 10:53:36AM -0400, Bruce Momjian wrote: > Someone just asked about a COPY capability to supply the column headings > as the first line of the copy statement. Do we want to support > something like that? Does anyone else want such functionality? Wouldn't it be more logical, and more compatible, to keep this information as regular column information in the PGresult returned by the COPY? Or would that clash with the difference between "command" and "query" result handling? Jeroen ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] COPY with column headings
Bruce Momjian wrote: Someone just asked about a COPY capability to supply the column headings as the first line of the copy statement. Do we want to support something like that? Does anyone else want such functionality? I had it in mind all along as a possible option for CSV mode, but given the heat that was generated by the minimal implementation we did, I thought I'd let it rest. I certainly think it's worth considering, although I see Tom has objected :-) . Say we have an option called FIRSTLINELABELS, then on copy out it would write the headings on the first line, and on copy in it could just ignore the first line (so it could work symmetrically). cheers andrew ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] COPY with column headings
Andrew Dunstan wrote: > > > Bruce Momjian wrote: > > >Someone just asked about a COPY capability to supply the column headings > >as the first line of the copy statement. Do we want to support > >something like that? Does anyone else want such functionality? > > > > > > > > I had it in mind all along as a possible option for CSV mode, but given > the heat that was generated by the minimal implementation we did, I > thought I'd let it rest. > > I certainly think it's worth considering, although I see Tom has > objected :-) . Say we have an option called FIRSTLINELABELS, then on > copy out it would write the headings on the first line, and on copy in > it could just ignore the first line (so it could work symmetrically). Yes, that is what I was thinking. Is this a TODO? Sure it can be misused but most copy options can be similarly misused. -- 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
Re: [HACKERS] COPY with column headings
"Jeroen T. Vermeulen" <[EMAIL PROTECTED]> writes: > Wouldn't it be more logical, and more compatible, to keep this information > as regular column information in the PGresult returned by the COPY? That would work but would require a protocol change, which this is surely not worth by itself. (We could put it on the to-do list for the next protocol rev though.) The bigger question is whether this would do anything to satisfy the requestor. He probably wants the headings to appear in the file resulting from COPY TO file (or the psql equivalent), which this would not do. Providing the info in the COPY PGresult would change nothing except the behavior of client applications specially rewritten to use it. regards, tom lane ---(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] COPY with column headings
On Mon, Aug 16, 2004 at 11:30:49AM -0400, Tom Lane wrote: > The bigger question is whether this would do anything to satisfy the > requestor. He probably wants the headings to appear in the file > resulting from COPY TO file (or the psql equivalent), which this would > not do. Providing the info in the COPY PGresult would change nothing > except the behavior of client applications specially rewritten to use it. True, and from a compatibility standpoint that would probably be good... Output post-processing (translation to CSV or XML output, XSLT transforms, what have you) IMHO should probably go on top of COPY anyway, rather than into it. Are people really having problems with select * from table where 1=0 ; copy table to stdout and first printing the column names found in the first PGresult, then dumping the COPY lines to the same fd? I think that should do the trick for most uses, although obviously I'm no expert. Jeroen ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] COPY with column headings
Bruce Momjian <[EMAIL PROTECTED]> writes: >> I certainly think it's worth considering, although I see Tom has >> objected :-) . Say we have an option called FIRSTLINELABELS, then on >> copy out it would write the headings on the first line, and on copy in >> it could just ignore the first line (so it could work symmetrically). > Yes, that is what I was thinking. Is this a TODO? Sure it can be > misused but most copy options can be similarly misused. Most copy options will result in obvious failures if misused. I dislike this one because of the high risk of silent corruption of your data (loss of a row or insertion of a row that shouldn't be there). Considering no one has even made a positive case why we should add it (for instance, a use-case where it's necessary), I don't think it belongs in the to-do list. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
HASHes [was Re: [HACKERS] Calling PL functions with named parameters]
On Fri, Aug 13, 2004 at 07:12:14PM -0400, Tom Lane wrote: > "Jim C. Nasby" <[EMAIL PROTECTED]> writes: > > IOW, their function resolution code treats a(int, int default 0) > > as being equivalent to a(int) and a(int, int). > > So you are willing to prohibit a(int) from existing in parallel with > a(int, int-with-a-default) ? > > I'll be interested to see the unique-index scheme for pg_proc to > enforce that ;-) > > However this does point up the fact that there already *is* a way to > accomplish the task, which is just to create some helper function(s) > to supply the default(s). Perhaps we can leave it at that for the > time being, and concentrate on adding real new functionality. That'd be neat. :) Here's another possibility. PostgreSQL has already "gone there" with multidimensional ARRAYs, and thanks, Joe! What about making HASHes a first-class object? This would do two controversial things (that I've thought of). 1. Use the => operator, removing it from the pool of unused operators. 2. Possibly encourage people to Do The Wrong Thing(TM). What we'd get for the effort, though, is tighter integration with languages that have some kind of associative array structure, which is to say all the "scripting" languages, and an ability to deal with data structures to and from queries that more closely matches what the middleware/front end needs to do. How big a can of worms am I opening here? Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: HASHes [was Re: [HACKERS] Calling PL functions with named parameters]
David Fetter <[EMAIL PROTECTED]> writes: > What about making HASHes a first-class object? I see less than zero value in this. You'd have to serialize the contents to ship it to the client anyway, so there is no particular point in inventing a random new representation for "row". regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] pg_subtrans and WAL
Added to open items: * determine proper crash recovery/logging for pg_subtrans --- Alvaro Herrera Munoz wrote: > On Tue, Aug 10, 2004 at 12:24:06PM -0400, Tom Lane wrote: > > My discovery last night of a WAL synchronization error in pg_clog led me > > to take a look at pg_subtrans too. I soon realized that in fact we are > > not WAL-logging pg_subtrans updates at all: subtransaction start sets up > > a pg_subtrans entry but makes no WAL entry for this action. > > > > Seems like this is a problem. > > Rats :-( > > You are probably right. In fact this was on my todo list and I overlooked > it -- it was mentioned during early discussion. > > Right now I am heading to Bolivia for a conference, so I am not able to > do anything codewise right now, and I'll most likely have very intermitent > connection ... I'll be back on monday 16. > > -- > Alvaro Herrera (<[EMAIL PROTECTED]>) > "Estoy de acuerdo contigo en que la verdad absoluta no existe... > El problema es que la mentira s? existe y tu est?s mintiendo" (G. Lama) > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Tablespace issues (comment on ,moving indexes)
Added to TODO; o Add ALTER INDEX syntax to work like ALTER TABLE indexname --- Christopher Kings-Lynne wrote: > > What I mean here is that I think it would be in our best interests to > > define the syntax for any new operation to be as easily guessed as > > possible. I believe that ALTER INDEX would be more easily guessed by > > more people as the means by which one would alter an index's tablespace > > than ALTER TABLE, even if those people have a decent amount of PG > > experience. > > I agree. Whether or not it gets done though is the question... > > Chris > > > ---(end of broadcast)--- > TIP 4: Don't 'kill -9' the postmaster > -- 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] Calling PL functions with named parameters
Tom, > I agree however with Andrew's nearby point that this is completely > unrelated to named parameters to functions/procedures, or to defaults > for parameters. I think that was Peter's point, not Andrew's.Andrew agreed with me. I do think, though, that we should hammer out the parameters, functions, procedures, etc. "master plan" before anyone gets further coding them, if people are up for it. Tom, just to be perfectly clear about why I see Procedures as a way of resolving parameter ambiguity, my idea is that: FUNCTIONS will support overloading but will not support named parameter calling; PROCEDURES will support named parameter calling but not support overloading. This resolves the ambiguity. Particularly, I'm concerned about adding any more code to the evaluation of a function call, out of fear that it will have a significant performance impact due to increased time to evaluate built-in functions. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Calling PL functions with named parameters
Josh Berkus <[EMAIL PROTECTED]> writes: > Tom, just to be perfectly clear about why I see Procedures as a way of > resolving parameter ambiguity, my idea is that: > FUNCTIONS will support overloading but will not support named parameter > calling; > PROCEDURES will support named parameter calling but not support overloading. Understood, but this seems like a bad design to me, because it's non-orthogonal. > Particularly, I'm concerned about adding any more code to the > evaluation of a function call, out of fear that it will have a > significant performance impact due to increased time to evaluate > built-in functions. I think that named params would have no significant extra cost *when not used*, so I'm not sure the above concern is a big deal. (I do worry about the cost implications of defaultable parameters, however, as that seems likely to expand the search space for a matching function quite a bit.) regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Open items
>>> Does anyone have any more? > >> win32 signal safe socket handler > >I thought that was solved long ago? If this is what I think it is (Merlin - please confirm), this relates to the SSL code only. And the issue is that there are (I think - haven't 100% verified it yet) paths in the SSL code that will block withou it being possible to deliver signals. The end result would be a query you can't cancel/backend you can't kill. The non-SSL codepaths emulate blocking sockets using non-blocking ones that also listen on signals. This has not been done for SSL sockets yet. //Magnus ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Timezone for %t log_line_prefix
>> That's ugly, and unfortunately %z is GNU-specific. > >Does Windows' strftime have any short zone name %-spec? Seems like a >quick #ifdef WIN32 to use a more compact zone name would be the best >solution. No. This is what the cruft in pgtz.c (TZABBREV macro and associated function) was all about. //Magnus ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Timezone for %t log_line_prefix
>Since we do have control over the timezone library now, one possible >answer is to extend the src/timezone API so that it's possible to >convert/format against more than a single timezone. We could then >remember the zone setting inherited from the postmaster and always use >that when formatting timestamps for the log, while not changing the >behavior for operations at the SQL level. Time permitting, I was planning to address this in 8.1. (well, 7.6 then, but I guess it's 8.1 now). Not specificalyl the issue, but the groundwork API change to make it possible. >However, this is probably a bit more work than is reasonable to >undertake right now, when we're already overdue for beta. Definitly. //Magnus ---(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] Open items
Magnus Hagander wrote: > >>> Does anyone have any more? > > > >> win32 signal safe socket handler > > > >I thought that was solved long ago? > > If this is what I think it is (Merlin - please confirm), this relates to > the SSL code only. And the issue is that there are (I think - haven't > 100% verified it yet) paths in the SSL code that will block withou it > being possible to deliver signals. The end result would be a query you > can't cancel/backend you can't kill. OK, I added an SSL mention: o fix signal safe socket handler for SSL > > The non-SSL codepaths emulate blocking sockets using non-blocking ones > that also listen on signals. This has not been done for SSL sockets yet. OK. -- 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
Re: [HACKERS] Open items
Sorry for the late reply, missed your initial response. > "Merlin Moncure" <[EMAIL PROTECTED]> writes: > >> Does anyone have any more? > > > win32 signal safe socket handler > > I thought that was solved long ago? As magnus wrote, we need to confirm that ssl sockets don't block singals while waiting or they will not execute signals until a query runs. > > win32 query cancel in psql (?) > > What's the issue here? Win32 ctrl-c handler runs in a separate thread which ultimately calls TerminateProcess(). Problem is does an immediate kill which does not send the cancel signal to the backend. The solution is to install a custom ctrl-c handler (in fact a patch was submitted to do this) which fires the appropriate signal. However, this code runs a separate thread...the original patch (by Luf) was rejected because it did not address thread safety issues. Merlin ---(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] COPY with column headings
Tom Lane wrote: Bruce Momjian <[EMAIL PROTECTED]> writes: I certainly think it's worth considering, although I see Tom has objected :-) . Say we have an option called FIRSTLINELABELS, then on copy out it would write the headings on the first line, and on copy in it could just ignore the first line (so it could work symmetrically). Yes, that is what I was thinking. Is this a TODO? Sure it can be misused but most copy options can be similarly misused. Most copy options will result in obvious failures if misused. I dislike this one because of the high risk of silent corruption of your data (loss of a row or insertion of a row that shouldn't be there). Considering no one has even made a positive case why we should add it (for instance, a use-case where it's necessary), I don't think it belongs in the to-do list. The use case is that it fits in with the way spreadsheets usually do data tables, and many will only allow you to export a whole worksheet (including the heading row) to CSV, not a part of one. Conversely, working with imported data tables will be harder if they lack headings. cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] COPY with column headings
Andrew Dunstan <[EMAIL PROTECTED]> writes: > The use case is that it fits in with the way spreadsheets usually do > data tables, and many will only allow you to export a whole worksheet > (including the heading row) to CSV, not a part of one. Conversely, > working with imported data tables will be harder if they lack headings. Well, if we wanted to *require* a heading row in CSV mode, it would be relatively foolproof. What I don't like is the proposal for an independent option; you've got a 50-50 chance of getting it wrong on import, and that's too high odds for me. Next question: are you imagining that the header row will actually have any semantic significance on input? Will we check the column names? Will we be willing to rearrange the columns if the header row claims the column order is different than the COPY command says? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] COPY with column headings
Tom Lane wrote: Andrew Dunstan <[EMAIL PROTECTED]> writes: The use case is that it fits in with the way spreadsheets usually do data tables, and many will only allow you to export a whole worksheet (including the heading row) to CSV, not a part of one. Conversely, working with imported data tables will be harder if they lack headings. Well, if we wanted to *require* a heading row in CSV mode, it would be relatively foolproof. What I don't like is the proposal for an independent option; you've got a 50-50 chance of getting it wrong on import, and that's too high odds for me. No, we can't require it. Not all will have headers, and then we sure would skip a wanted row. And while my use case referred to spreadsheets, they are not the only sources/recipients of CSVs. Your 50-50 chance assumes the user knows nothing about the data and uses the switch at random. I think we're entitled to assume the user knows something about their data and uses the switch according to what they have/want. Right now, if you have a CSV with a header line you have to remove the line with something like 'sed 1d' before importing to PostgreSQL, and when importing from PostgreSQL you have to insert the headers manually after importing the CSV to your spreadsheet. That's got to be annoying and at least as error-prone as providing a switch to accomodate header lines. Next question: are you imagining that the header row will actually have any semantic significance on input? Will we check the column names? Will we be willing to rearrange the columns if the header row claims the column order is different than the COPY command says? I'm leaning towards not trying to interpret the line on copy in. Certainly that is the minimalist way to approach this. cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] COPY with column headings
Might be worthwhile to look at SQL*Server BCP format files: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adminsq l/ad_impt_bcp_9yat.asp http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref /ts_ba-bz_4fec.asp A TCL/TK front end would be especially nice. Of course, being a lazy slug, I am not volunteering to write any of this. Just a thought in case someone else is interested in doing it. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Tom Lane > Sent: Monday, August 16, 2004 12:04 PM > To: Andrew Dunstan > Cc: Bruce Momjian; PostgreSQL-development > Subject: Re: [HACKERS] COPY with column headings > > > Andrew Dunstan <[EMAIL PROTECTED]> writes: > > The use case is that it fits in with the way spreadsheets usually do > > data tables, and many will only allow you to export a whole > worksheet > > (including the heading row) to CSV, not a part of one. Conversely, > > working with imported data tables will be harder if they > lack headings. > > Well, if we wanted to *require* a heading row in CSV mode, it > would be relatively foolproof. What I don't like is the > proposal for an independent option; you've got a 50-50 chance > of getting it wrong on import, and that's too high odds for me. > > Next question: are you imagining that the header row will > actually have any semantic significance on input? Will we > check the column names? Will we be willing to rearrange the > columns if the header row claims the column order is > different than the COPY command says? > > regards, tom lane > > ---(end of > broadcast)--- > TIP 6: Have you searched our list archives? > http://archives.postgresql.org ---(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] COPY with column headings
Tom Lane wrote: > Andrew Dunstan <[EMAIL PROTECTED]> writes: > > The use case is that it fits in with the way spreadsheets usually do > > data tables, and many will only allow you to export a whole worksheet > > (including the heading row) to CSV, not a part of one. Conversely, > > working with imported data tables will be harder if they lack headings. > > Well, if we wanted to *require* a heading row in CSV mode, it would be > relatively foolproof. What I don't like is the proposal for an > independent option; you've got a 50-50 chance of getting it wrong on > import, and that's too high odds for me. But we have other CVS options with even lower odds of success on a random guess. People have to know if their input file has headings, period. Telling people they can't have the option because they might get it wrong seems strange to me. > Next question: are you imagining that the header row will actually have > any semantic significance on input? Will we check the column names? > Will we be willing to rearrange the columns if the header row claims the > column order is different than the COPY command says? I assume no semantic significance to header row values on input. -- 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
Re: [HACKERS] [ADMIN] SRPM for 8.0.0 beta?
Joe Conway wrote: Steve Bergman wrote: Anyone have an SRPM of spec file for the beta? I just created and posted a source RPM for 8.0.0beta1. As I'm not the usual packager, and a pure hack when it comes to building my own RPMs, it would be a Good Thing(tm) if someone else could vet this package; available here: http://www.joeconway.com/postgresql-8.0.0beta1/ There are binaries for Fedora Core 2 there as well. I actually tried to use my own rpm today, and discovered a mistake resulting in a non-working install. Sorry for that, to those of you who grabbed a copy. Version 2 of the source rpm is now available here: http://www.joeconway.com/postgresql-8.0.0beta1/SRPM/postgresql-8.0.0beta1-2PGDG.src.rpm I've also put up i386 binary rpms for fc1 and fc2, and x86_64 binary rpms for fc2. 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] [ADMIN] Pseudo-Off-topic-survey: Opinions about future of Postgresql(MySQL)?
# This message was accidentally sent only to Bruce. It's pasted here for comment from the rest of the list too :) Folks, While on the topic of Ingres and open source, I was wondering whether there's interest in an effort to port some of the enterprise-grade features from Ingres over to Postgres e.g. what Enrique mentioned (clustering, load balancing, replication etc). I've never dabbled in the internals of postgres before but I'd be willing to lend a hand in any way to get those features into Postgres. Shahbaz Javeed On Fri, 13 Aug 2004 22:29:09 -0400 (EDT), Bruce Momjian <[EMAIL PROTECTED]> wrote: > Enrique Arizón wrote: > > Now that CA has open sourced Ingres what future do > > you guess to Postgresql and MySQL? > > > > Don't missunderstand me, I have been using Postgresql > > for more than 3 years and developing apps against it > > and all I got is possitive impressions, but comparing > > the upcoming 8.0 (7.5) release with Ingres, it looks > > that Ingres is much more advanced (clustering, > > load-balancing, XML, ...) and the main advantage > > Postgresql had in its open source nature looks to be > > vanished. More one, CA looks really serious about > > Ingres that now is a core tool in more of 100 > > derivates CA products, and it's said they had doubled > > the number of Ingres developers. Also the new version > > provides a great compatibility with Oracle and > > "easify" Oracle to Ingres port. Is there any OBJETIVE > > reason not to change to Ingres? > > Good question. We heard the same things when SapDB came out. SapDB was > moved into the MySQL AB company and renamed MaxDB. I don't think there > is any more community development of it, just like MySQL. > > Basically, what we have is quality code and a vibrant community. Those > aren't easy to create. In fact, that's what makes open source powerful. > > -- > 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 9: the planner will ignore your desire to choose an index scan if your > joining column's datatypes do not match > -- Shahbaz Javeed ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] OT: Want to blog on PostgreSQL.org?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Many hackers worked for PostgreSQL 8.0.0 release, which was one of the most active development period of PostgreSQL history. We got too many contributors for this release which is a great success, I think. A lot of other OSS projects seem to have very popular developer blogging sites, like planetapache.org. What about a PostgreSQL blog? How many "major contributors" would use a blog if one was available? Especially before the 8.0.0 release. Regards, - -- Devrim GUNDUZ devrim~gunduz.org devrim.gunduz~linux.org.tr http://www.tdmsoft.com http://www.gunduz.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBISBgtl86P3SPfQ4RAj2eAKCn+wMV5n9waq6ShlktDzclbhjjUgCfQouX mFJ2HJmpqufxxRDAiwJIngw= =LKUz -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Tablespace issues (comment on ,moving indexes)
I posted a patch for this last Friday 13th. Gavin On Mon, 16 Aug 2004, Bruce Momjian wrote: > > Added to TODO; > > o Add ALTER INDEX syntax to work like ALTER TABLE indexname > > --- > > Christopher Kings-Lynne wrote: > > > What I mean here is that I think it would be in our best interests to > > > define the syntax for any new operation to be as easily guessed as > > > possible. I believe that ALTER INDEX would be more easily guessed by > > > more people as the means by which one would alter an index's tablespace > > > than ALTER TABLE, even if those people have a decent amount of PG > > > experience. > > > > I agree. Whether or not it gets done though is the question... > > > > Chris > > > > > > ---(end of broadcast)--- > > TIP 4: Don't 'kill -9' the postmaster > > > > -- > 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 > > > !DSPAM:4120de11152569085518527! > > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] pulling projection up in plans
Hi, is there a way to pull the projection operator to the top of the query plan? I wish there's a variable that can be set to do so. Thanks, --h ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] to_char() and negative intervals
On Mon, Aug 16, 2004 at 10:43:10AM -0400, Bruce Momjian wrote: > Karel Zak wrote: > > On Fri, Aug 13, 2004 at 12:24:28PM -0400, Tom Lane wrote: > > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > > Someone on IRC just reported this to_char() failure with negative > > > > intervals: > > > > > > I think Karel wanted to remove to_char(interval) altogether. > > > > Yes, the notice about it is already in 7.4 docs. Maybe we can remove > > it in 7.5/8.0. Comments? > > I don't see how we can remove it in 8.0 unless we require an initdb. > What we could do is to throw an error/warning in the code and remove it > completely in 8.1. If we force an initdb for some other reason during beta, we can remove to_char(interval) at that point too ... -- Alvaro Herrera () "Siempre hay que alimentar a los dioses, aunque la tierra esté seca" (Orual) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Calling PL functions with named parameters
Tom, > Understood, but this seems like a bad design to me, because it's > non-orthogonal. Or just a natural consequence of our having loaded Functions down with all of the functionality usually assigned to Procedures over the years. > I think that named params would have no significant extra cost *when not > used*, so I'm not sure the above concern is a big deal. (I do worry > about the cost implications of defaultable parameters, however, as that > seems likely to expand the search space for a matching function quite a > bit.) Well, since default params is one of the critical reasons to use named param calling in the first place, I think this is a significant concern. I'm also not looking forward to all of the "help" e-mails we'll get to PGSQL-SQL in response to: "Your function cannot be created as specified due to a namespace conflict." ... particularly if this happens during database reload as a result of new functions in Template1. -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] to_char() and negative intervals
Added to open items: * remove to_char(interval) if we initdb --- Alvaro Herrera wrote: > On Mon, Aug 16, 2004 at 10:43:10AM -0400, Bruce Momjian wrote: > > Karel Zak wrote: > > > On Fri, Aug 13, 2004 at 12:24:28PM -0400, Tom Lane wrote: > > > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > > > Someone on IRC just reported this to_char() failure with negative > > > > > intervals: > > > > > > > > I think Karel wanted to remove to_char(interval) altogether. > > > > > > Yes, the notice about it is already in 7.4 docs. Maybe we can remove > > > it in 7.5/8.0. Comments? > > > > I don't see how we can remove it in 8.0 unless we require an initdb. > > What we could do is to throw an error/warning in the code and remove it > > completely in 8.1. > > If we force an initdb for some other reason during beta, we can remove > to_char(interval) at that point too ... > > -- > Alvaro Herrera () > "Siempre hay que alimentar a los dioses, aunque la tierra est? seca" (Orual) > > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] pulling projection up in plans
"Hicham G. Elmongui" <[EMAIL PROTECTED]> writes: > is there a way to pull the projection operator to the top of the query > plan? I wish there's a variable that can be set to do so. Could you be more specific about what you're hoping to accomplish? regards, tom lane ---(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] OT: Want to blog on PostgreSQL.org?
On Tue, 17 Aug 2004, Devrim GUNDUZ wrote: stupid question, but what *is* a blog? Hi, Many hackers worked for PostgreSQL 8.0.0 release, which was one of the most active development period of PostgreSQL history. We got too many contributors for this release which is a great success, I think. A lot of other OSS projects seem to have very popular developer blogging sites, like planetapache.org. What about a PostgreSQL blog? How many "major contributors" would use a blog if one was available? Especially before the 8.0.0 release. Regards, - -- Devrim GUNDUZ devrim~gunduz.org devrim.gunduz~linux.org.tr http://www.tdmsoft.com http://www.gunduz.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBISBgtl86P3SPfQ4RAj2eAKCn+wMV5n9waq6ShlktDzclbhjjUgCfQouX mFJ2HJmpqufxxRDAiwJIngw= =LKUz -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] OT: Want to blog on PostgreSQL.org?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On Mon, 16 Aug 2004, Marc G. Fournier wrote: > stupid question, but what *is* a blog? http://dotnet.org.za/armand/archive/0001/01/01/1172.aspx "A blog is basically a journal that is available on the web. The activity of updating a blog is "blogging" and someone who keeps a blog is a "blogger." Blogs are typically updated daily using software that allows people with little or no technical background to update and maintain the blog. Postings on a blog are almost always arranged in chronological order with the most recent additions featured most prominently. " "Slang term for a weblog. A Web log, for the uninitiated, is a popular and fairly personal content form on the Internet. A person's Web log is almost like an open diary. It chronicles what a person wants to share with the world on an almost daily basis. " Or easily: http://www.webopedia.com/TERM/B/blog.html :) You can also visit planetapache.org to see what's happening there. Regards, - -- Devrim GUNDUZ devrim~gunduz.org devrim.gunduz~linux.org.tr http://www.tdmsoft.com http://www.gunduz.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBIUoLtl86P3SPfQ4RAi/YAJ4/WJdyzTAbajeVQ2aJ7kEwiVyevACg00KE L6Iu3gqPB5K6eYrku8z4lQY= =EC18 -END PGP SIGNATURE- ---(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] pulling projection up in plans
> "Tom" == Tom Lane <[EMAIL PROTECTED]> writes: Tom> "Hicham G. Elmongui" <[EMAIL PROTECTED]> writes: >> is there a way to pull the projection operator to the top of >> the query plan? I wish there's a variable that can be set to do >> so. Tom> Could you be more specific about what you're hoping to Tom> accomplish? This is just a suspicion, but I suspect that Hicham wants to avoid tuples being projected in Scan operators .. in a select (*) query projecting a tuple essentially causes a copy from the buffer pool to the backend process' heap space. I guess it would work just fine to have the tuple remain in the buffer and keep the buffer pinned. (In TelegraphCQ we actually do this .. we also don't really materialize join tuples - instead we have an "intermediate tuple format" which is a list of pointers to the various source tuples. This makes sense as we do shared query processing - ie. different queries with similar join predicates and different projection attributes use the same physical join tuples - projection is the final operation on the intermediate tuples when we return the tuples to clients. We did this really to facilitate sharing and don't really have any hard numbers on whether this would make sense in a general context with pgsql. Actually IIRC we did consider this - if this would make a diff to pgsql - and did some crude perf studies and found that it didn't really help if there was no sharing .. as is the case with pgsql). -- Pip-pip Sailesh http://www.cs.berkeley.edu/~sailesh ---(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] Release notes for upgrading
On Wed, 11 Aug 2004, Robert Treat wrote: On Wed, 2004-08-11 at 01:11, Tom Lane wrote: Robert Treat <[EMAIL PROTECTED]> writes: On Tuesday 10 August 2004 22:57, Christopher Kings-Lynne wrote: I don't think many users realise they can use the next version's pg_dump to upgrade. I think it should be put in every release notes! Assuming we're not ready to recommend Slony for upgrades, I would second this idea based on my experience of several cases where I *had* to dump a database using the newer pg_dump to get it to upgrade reliably. This has been standard lore for awhile. Where should we document it exactly? Actually it seems it is already mentioned in http://developer.postgresql.org/docs/postgres/install-upgrading.html and somewhat inferred in http://developer.postgresql.org/docs/postgres/migration.html I'll take a swing at making the language a little stronger. We could also add it as a mailing list hint. Chris, you have any other ideas where you would like to see it? Exact text you'd like to have added? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] COPY with column headings
That'd likely be useful. Either specify the column names with COPY or \copy, or put them in the data file and pass an option to the command to look for them. The only time this could be a problem is if you forget to tell COPY to look for the field names in the file (AND specify the field names to COPY), and the values for the field names are such that they don't cause data errors (probably pretty slim chance). I'd also really like to see the ability to specify default values for fields not included in the data file (field defaults in the table definition is limited and doesn't fill the order when you need to specify various foreign key ids, specific times, etc.). CSN >>> Someone just asked about a COPY capability to supply the column headings as the first line of the copy statement. Do we want to support something like that? Does anyone else want such functionality? __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail ---(end of broadcast)--- TIP 8: explain analyze is your friend
