On Fri, 2009-02-27 at 22:55 -0500, Andrew Dunstan wrote:
>
> Hannu Krosing wrote:
> >>>
> >>>
> >> Some of the functions, including some specified in the standard, produce
> >> fragments. That's why we have the 'IS DOCUMENT&#x
On Sun, 2009-03-01 at 10:13 -0500, Andrew Dunstan wrote:
>
> Hannu Krosing wrote:
> >> Some of the functions, including some specified in the standard, produce
> >> fragments. That's why we have the 'IS DOCUMENT' test.
> >>
> >
> >
lly when that
> is so ill-defined in the case of fragments.
Is it just that in you _can't_ use Xpath on fragments, and you _need_ to
pass full documents to Xpath ?
At least this is my reading of Xpath standard.
> cheers
>
> andrew
--
Hannu Krosing http://www.2ndQuadrant.com
Po
On Mon, 2009-03-02 at 15:25 +0200, Peter Eisentraut wrote:
> Hannu Krosing wrote:
> > Is it just that in you _can't_ use Xpath on fragments, and you _need_ to
> > pass full documents to Xpath ?
> >
> > At least this is my reading of Xpath standard.
>
> It i
ld that there is enough of a user base for it to justify the
> effort we'll have to put into it. If there were, we'd be seeing more
> interest in reviewing it.
Can't it be kept separately maintained release for a version or two, so
that we will have both PostgreSQL and SE-Post
at
> the head of themself without doing anything.
>
> I believe this behavior follows the previous suggestion.
Have you been able to measure any speed difference between
--enable-selinux on and off ?
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Serv
are ratios of running times - maybe with 2-3X tolerance - to catch
most obvious regressions ?
> regards, tom lane
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Consulting and Training
--
Sent via pgsql-hackers mai
"COMMIT;" somewhere ? ;)
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Consulting and Training
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mail
ring those parts into using newer
structures and functions :)
And I also think that pl/python, even for python 2.x does need lots of
refactoring in most places in order to be maintainable.
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Consul
hexd41d8cd98f00b204e9800998ecf8427e'
>
> With a bit of extra work we can wrap this up to be a more or less SQL-
> conforming blob type, which would also make a lot of people very happy.
And we can also escape the need to uncompress TOAST'ed fields - just
markup the compression as an
cape minimal amount of characters, probably
just \0 , \n and \\
--
Hannu Krosing http://www.2ndQuadrant.com
PostgreSQL Scalability and Availability
Services, Consulting and Training
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://
On Thu, 2002-04-11 at 18:14, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > On the other hand, there are already a few reasons to make some
> > changes to the FE/BE protocol (NOTIFY messages, transaction state,
> > and now possibly PREPARE/EXECUTE -- anything else?).
>
> Passing EX
On Thu, 2002-04-11 at 22:48, Tom Lane wrote:
> Barry Lind <[EMAIL PROTECTED]> writes:
> > ...
> > Since we
> > don't currently provide any information to the user on the relative cost
> > of the parse, plan and execute phases, the end user is going to be
> > guessing IMHO.
>
> You can in fact
On Fri, 2002-04-12 at 03:04, Brian Bruns wrote:
> On 11 Apr 2002, Hannu Krosing wrote:
>
> > IIRC someone started work on modularising the network-related parts with
> > a goal of supporting DRDA (DB2 protocol) and others in future.
>
> That was me, although I've
On Sat, 2002-04-13 at 17:29, Tom Lane wrote:
> [ way past time to change the title of this thread ]
>
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > OK, sounds fair. However, is there a more aggressive way of reclaiming the
> > space? The problem with updating all the rows to null
On Sun, 2002-04-14 at 08:48, Lamar Owen wrote:
>
> Incidentally, the 7.2.93 (skipjack) public beta is a serious improvement over
> RHL 7.2, and I personally recommend it, as KDE 3 is worth the upgrade, even
> to a beta.
Is the 7.2.93 (skipjack) public beta an improvement in raw postgresql
perf
On Tue, 2002-04-16 at 07:01, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > How about this: We store the first 16 parameters in some fixed array for
> > fast access like now, and when you have more than 16 then 17 and beyond
> > get stored in some variable array in pg_proc.
>
On Tue, 2002-04-16 at 03:20, Tatsuo Ishii wrote:
> In my understanding, our consensus was enabling multibyte support by
> default for 7.3. Any objection?
Is there currently some agreed plan for introducing standard
NCHAR/NVARCHAR types.
What does ISO/ANSI say about multybyteness of simple CHAR t
On Wed, 2002-04-17 at 22:43, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > OTOH, it is also important where the file is on disk. As seen from disk
> > speed test graphs on http://www.tomshardware.com , the speed difference
> > of sequential reads is 1
On Fri, 2002-04-19 at 05:28, Peter Eisentraut wrote:
> Tom Lane writes:
>
> > Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> > > Can we enable syslog support by default for 7.3?
> >
> > AFAIR, we agreed to flip the default some time ago, we just didn't
> > want to do it late in the 7.2 cycle. Go for
On Fri, 2002-04-19 at 08:15, Tatsuo Ishii wrote:
> > > > > Can we enable syslog support by default for 7.3?
> > > >
> > > > AFAIR, we agreed to flip the default some time ago, we just didn't
> > > > want to do it late in the 7.2 cycle. Go for it.
> > >
> > > I think if no one complains about the
On Tue, 2002-04-23 at 01:29, Martijn van Oosterhout wrote:
>
> The dumping is more of an extra, the original idea was to check for errors
> in the datafiles. Hence the working name of "pgfsck". At the moment the
> dumping dumps only tuples where xmax == 0 but I'm not sure if that's
> correct.
AF
On Tue, 2002-04-23 at 12:52, Martijn van Oosterhout wrote:
> Well, from my thinking about how you would use these fields in a logical
> way, it seems it's possible for xmax to be non-zero if the transaction
> numbered xmax was not committed. But in that case (unless it was a delete)
> there would
On Thu, 2002-04-25 at 00:46, mlw wrote:
> We have had several threads about index usage, specifically when PostgreSQL has
> the choice of using one or not.
>
> There seems to be a few points of view:
>
> (1) The planner and statistics need to improve, so that erroneously using an
> index (or not
On Thu, 2002-04-25 at 08:42, Luis Alberto Amigo Navarro wrote:
> >
> > (2) Use programmatic hints which allow coders specify which indexes are
> used
> > during a query. (ala Oracle)
> >
> As I said before it would be useful a way to improve(not force) using
> indexes on particular queries, i.e. l
On Thu, 2002-04-25 at 12:47, Curt Sampson wrote:
> On Thu, 25 Apr 2002, Lincoln Yeoh wrote:
>
> > I think the raw partitions will be more trouble than they are worth.
> > Reading larger chunks at appropriate circumstances seems to be the "low
> > hanging fruit".
>
> That's certainly a good start
On Fri, 2002-04-26 at 07:38, Curt Sampson wrote:
> On Thu, 25 Apr 2002, Bruce Momjian wrote:
>
> > WAL files are kept only until an fsync(), checkpoint, then reused.
>
> One could keep them longer though, if one really wanted to.
>
> > Also, the info is tied to direct locations in the file. Yo
On Fri, 2002-04-26 at 19:41, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > DB2 can run in two modes
> > 1) similar to ours, where logs are reused after checkpoints/commits
> > allow it.
> > 2) with log archiving: logs are never reused, but
On Mon, 2002-04-29 at 17:09, Scott Marlowe wrote:
> For this reason, I propose that a transaction should "inherit" its
> environment, and that all changes EXCEPT for those affecting tuples should
> be rolled back after completion, leaving the environment the way we found
> it. If you need the
On Mon, 2002-04-29 at 17:30, Tom Lane wrote:
> Scott Marlowe <[EMAIL PROTECTED]> writes:
> > I've been thinking this over and over, and it seems to me, that the way
> > SETS in transactions SHOULD work is that they are all rolled back, period,
> > whether the transaction successfully completes O
On Mon, 2002-04-29 at 17:53, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Perhaps we could do
> > SET SET TO LOCAL TO TRANSACTION;
> > Which would affect itself and all subsequent SET commands up to
> > SET SET TO GLOBAL;
> > or end
On Mon, 2002-04-29 at 18:20, Tom Lane wrote:
> Thomas Lockhart <[EMAIL PROTECTED]> writes:
> > Rather than dismissing this out of hand, try to look at what it *does*
> > enable. It allows developers to tune specific queries without having to
> > restore values afterwards. Values or settings which
On Tue, 2002-04-30 at 03:35, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > Appears psql needs to know how to differentiate between it's own temp
> > tables and those of another connection.
>
> More generally, psql is as yet clueless about schemas.
>
> regression=# create schema fo
On Tue, 2002-04-30 at 03:35, Bruce Momjian wrote:
>
> I think you have to use the backend pid to find your own. I think
> there is a libpq function that returns the backend pis so psql can
> frame the proper query.
Is anyoune working on information schema (or pg_xxx views) for use in
psql and o
On Thu, 2002-05-02 at 05:33, Tom Lane wrote:
> "Nigel J. Andrews" <[EMAIL PROTECTED]> writes:
> > So, how does one determine the current schema for temporary tables,
> > i.e. what name would be in search_path if it wasn't implicitly included?
>
> The temp schema is pg_temp_nnn where nnn is your B
On Thu, 2002-05-02 at 14:37, Jim Mercer wrote:
> On Thu, May 02, 2002 at 08:15:15AM -0400, mlw wrote:
> > Who's that? Anyone disagree?
>
> why does it have to be THE BEST ? that is insulting to the other projects
> like MySQL which while "competitors" are also a valid and useful benchmark
> for
On Thu, 2002-05-02 at 15:48, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > On Thu, 2002-05-02 at 05:33, Tom Lane wrote:
> >> The temp schema is pg_temp_nnn where nnn is your BackendId (PROC array
> >> slot number). AFAIK there isn
On Thu, 2002-05-02 at 16:52, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Is "PROC array slot number" something internal to postgres ?
>
> Yes.
>
> If we used PID then we'd eventually have 64K (or whatever the range of
> PIDs is on
On Sat, 2002-05-04 at 21:56, Tom Lane wrote:
> mlw <[EMAIL PROTECTED]> writes:
> > We could provide a PGSemaphore based on an APR mutex and a counter,
> > but I'm not sure of the performance impact. We may want to implement
a
> > "generic" semaphore like this and one optimized for platforms which
On Sat, 2002-05-04 at 21:56, Tom Lane wrote:
> mlw <[EMAIL PROTECTED]> writes:
> > We could provide a PGSemaphore based on an APR mutex and a counter,
> > but I'm not sure of the performance impact. We may want to implement a
> > "generic" semaphore like this and one optimized for platforms which
On Tue, 2002-05-07 at 15:31, Tom Lane wrote:
> mlw <[EMAIL PROTECTED]> writes:
> > In the current CVS directory, there is pgsql/src/backend/port directory.
>
> > I propose that this become a separate subproject and library.
>
> Right offhand, that seems a pointless exercise in relabeling code th
On Thu, 2002-05-09 at 22:36, mlw wrote:
> Scott Marlowe wrote:
> > note
> > that many Unixes prefer multi-threaded models as well (Solaris comes to
> > mind) so there's the possibility that a multi-threaded postgresql could
> > enjoy better performance on more than just windows.
>
> The isolatio
On Thu, 2002-05-09 at 22:51, Jan Wieck wrote:
> Scott Marlowe wrote:
> > There are some issues that the whole idea of a win32 port should bring up.
> > One of them is whether or not postgresql should be rewritten as a
> > multi-threaded app.
>
> Please, don't add this one to it.
>
> I'm
On Fri, 2002-05-10 at 00:09, Hannu Krosing wrote:
> On Thu, 2002-05-09 at 22:51, Jan Wieck wrote:
> > Scott Marlowe wrote:
> > > There are some issues that the whole idea of a win32 port should bring up.
> > > One of them is whether or not postgresql should be rewritte
On Thu, 2002-05-09 at 19:23, mlw wrote:
> Lee Kindness wrote:
>
> >
> > Sure It'd be nice to have a native PostgreSQL on XP Server (I don't
> > see the point in consumer level Microsoft OSs) but how high is the
> > demand? What's the prize? What are the current limitations - fork,
> > semaphores
On Thu, 2002-05-09 at 19:25, Tom Lane wrote:
> mlw <[EMAIL PROTECTED]> writes:
> > I have used the cygwin version too. It is a waste of time. No Windows user will
> > ever accept it. No windows-only user is going to use the cygwin tools.
>
> With decent packaging, no windows-only user would even
On Fri, 2002-05-10 at 02:33, Dann Corbit wrote:
>
> It took a few hundred man hours to do it.
About 2-8 weeks for one full time programmer ?
> I see the whole Win32 port as
> a non issue. Several parties have already completed it (including the
> place where I work -- CONNX Solutions Inc.).
On Fri, 2002-05-10 at 06:27, Tom Lane wrote:
> I'm also concerned about having an understandable definition for the
> OID returned for an INSERT query --- if there are additional INSERTs
> triggered by rules, does that mean you don't get to see the OID assigned
> to the single row you tried to ins
On Sat, 2002-05-11 at 02:25, mlw wrote:
> A binary version of PostgreSQL for Windows should not use the cygwin dll. I
> know and understand there is some disagreement with this position, but in this
> I'm sure about this.
...
> I believe we can use the cygwin development environment, and direct
On Sat, 2002-05-11 at 02:25, Peter Eisentraut wrote:
> The remaining issue is the sort order. I think this can be solved for
> practical purposes by creating two expected files for each affected test,
> say char.out and char-locale.out. The regression test driver would try
> the first one, if th
On Thu, 2002-05-09 at 14:21, Mark kirkwood wrote:
> On Wed, 2002-05-08 at 01:45, Tom Lane wrote:
>
> > Which files grew exactly? (Main table, indexes, toast table, toast index?)
>
> Here a listing (from another run - I dumped and reloaded before getting
> any of that info last time...)
>
>
>
On Tue, 2002-05-14 at 04:03, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > Although this config file stuff is small potatoes compared to the
> > Win32 stuff as recently discussed. And for that, please understand
> > that most of the developers here consider Win32 an inferior server
On Tue, 2002-05-14 at 03:29, Tatsuo Ishii wrote:
> > I think it is really not hard to do this for UTF-8. I don't have to know the
> > relation between the locale and the encoding. Look at this:
> > We can use the LC_CTYPE from pg_controldata or alternatively the LC_CTYPE
> > at server startup. For
On Tue, 2002-05-14 at 09:52, Tatsuo Ishii wrote:
>
> Are you sure that say, de_DE.utf8 locale produce meaningful results
> for any other languages?
there are often subtle differences, but upper() and lower() are much
more likely to produce right results than collation order or date/money
formats
On Wed, 2002-05-15 at 23:23, Dann Corbit wrote:
> The select(min) and select(max) took as long as the table scan to find
> the count. It seems logical if a btree type index is available (such
> as pk_cnx_ds_sis_bill_detl_tb) where the most significant bit of the
> index is the column requested, i
On Thu, 2002-05-16 at 13:47, Joerg Hessdoerfer wrote:
> So, my route would be to get it to run *somehow* without paying attention to
> speed and not to change much of the existing code, THEN see how we could get
> rid of fork() on windows.
Getting it to compile and then "somehow" run on MinGW s
On Sun, 2002-05-19 at 19:37, Tom Lane wrote:
> Mark kirkwood <[EMAIL PROTECTED]> writes:
> > However I could not get any size stabilization in the toasted case.
>
> Hmm. Which file(s) were growing, exactly? How many row updates is this
> run covering?
>
> I'd rather expect the toast indexes to
On Sat, 2002-05-18 at 01:01, Tom Lane wrote:
> "Dave Page" <[EMAIL PROTECTED]> writes:
> > It doesn't work quite like that anyway.
>
> Oh, so essentially you want to simulate the namespace search on the
> application side. I see.
>
> > Anyway, current_schemas() seems ideal, thanks.
>
> It may
On Mon, 2002-05-20 at 16:08, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > On Sun, 2002-05-19 at 19:37, Tom Lane wrote:
> >> I'd rather expect the toast indexes to grow given the lack-of-btree-
> >> collapse-logic issue.
>
> > Why
On Fri, 2002-05-17 at 16:58, Michael Meskes wrote:
> Hi,
>
> IMO the most important stuff seems to be:
>
...
> - recursive views (you know, I wanted to implement this when I started
> my work on PostgreSQL, but never found the time)
A good start would be to make the parser recognize the full
On Tue, 2002-05-21 at 10:18, Michael Meskes wrote:
> On Tue, May 21, 2002 at 12:35:20AM +0500, Hannu Krosing wrote:
> > > - recursive views (you know, I wanted to implement this when I started
> > > my work on PostgreSQL, but never found the time)
> >
> >
On Tue, 2002-05-21 at 21:31, Trond Eivind Glomsrød wrote:
> On Tue, 21 May 2002, Lamar Owen wrote:
>
> > On Tuesday 21 May 2002 11:04 am, Manuel Sugawara wrote:
> > > I see. This behavior is consistent with the fact that mktime is
> > > supposed to return -1 on error, but then is broken in every
On Wed, 2002-05-22 at 02:14, Tom Lane wrote:
> =?ISO-8859-1?Q?Trond_Eivind_Glomsr=F8d?= <[EMAIL PROTECTED]> writes:
> > Relying on nonstandardized/nondocumented behaviour is a program bug, not a
> > glibc bug. PostgreSQL needs fixing. Since we ship both, we're looking at
> > it, but glibc is not
On Wed, 2002-05-22 at 12:28, Zeugswetter Andreas SB SD wrote:
> > 4. How exactly should a killed index tuple be marked on-disk? While there
> > is one free bit available in IndexTupleData.t_info, I would prefer to use
> > that bit to expand the index tuple size field to 14 bits instead of 13.
> >
On Wed, 2002-05-22 at 15:30, Thomas Lockhart wrote:
> > IIRC the spec is not _really_ broken - it still allows the correct
> > behaviour :)
>
> Yes.
>
> > The fact the ISO spec is broken usually means that at least one of the
> > big vendors involved in ISO spec creation must have had a broken
>
On Sat, 2002-05-25 at 02:38, Joe Conway wrote:
> Tom Lane wrote:
> > The remaining degradation is actually in seqscan performance, not
> > indexscan --- unless one uses a much larger -s setting, the planner will
> > think it ought to use seqscans for updating the "branches" and "tellers"
> > table
On Tue, 2002-05-28 at 21:52, Peter Eisentraut wrote:
> Louis-David Mitterrand writes:
>
> > Shouldn't plpgsql shortcut AND conditions when a previous one fails, as
> > perl does?
>
> Shouldn't perl evaluate all operands unconditionally, like plpgsql does?
>
> Seriously, if you want to change th
On Wed, 2002-05-29 at 02:36, Joel Burton wrote:
> > -Original Message-
> joel@joel=# select true and seeme();
> NOTICE: seeme
> ?column?
> --
> t
> (1 row)
>
>
> It certainly appears to be short circuiting for "select false and seeme()",
> for instance.
>
> It appears that th
On Fri, 2002-05-31 at 01:16, Josh Burdick wrote:
> BUG: this isn't properly set up to deal with multiple users.
> For example, if A computes a median, then B could read the data
> from the median_tmp table. Possibly you could fiddle with
> transaction isolation levels, or add a user field to medi
On Sun, 2002-05-26 at 21:55, Joe Conway wrote:
> Tom Lane wrote:
> >>3. PL/pgSQL support for returning sets -- this seems to me like an
> >>important item if SRFs are to be useful to the masses. Any pointers on
> >>how to approach this would be appreciated.
> >
> > Does Oracle's pl/sql support
On Thu, 2002-06-06 at 07:18, Tom Lane wrote:
> I've been having a lot of fun here at the SIGMOD annual conference,
> attaching faces to names like Stonebraker, Hellerstein, Aoki,
> Seltzer (if these do not ring a bell, you ain't read enough Postgres
> source code lately). I felt I had to pass alo
On Thu, 2002-06-06 at 21:13, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> >
> > One thing I think we have stripped too much is time travel.
>
> Actually, I was just discussing that at last night's dinner with someone
> whose name I forget at t
On Mon, 2002-06-10 at 09:58, Karel Zak wrote:
> On Fri, Jun 07, 2002 at 06:48:31PM -0700, Thomas Lockhart wrote:
> >
> > > Proposal #4: Create to_char(INTERVAL, 'format string') Function.
> > > Reason: self-evident, I think.
> >
> > Oh. Didn't know it wasn't already there.
>
> I'm _sure_ tha
On Mon, 2002-06-10 at 10:49, Karel Zak wrote:
>
> > > I'm _sure_ that to_char() is there for interval.
> > >
> > > testt=# select to_char('33s 15h 10m 5month'::interval, 'HH:MI:SS Month');
> > > to_char
> > >
> > > 03:10:33 May
> > > (1 row)
> >
> > Does "May
On Mon, 2002-06-10 at 15:43, Karel Zak wrote:
> On Mon, Jun 10, 2002 at 04:26:47PM +0200, Hannu Krosing wrote:
>
> > > to_char() convert interval to 'tm' and make output like this struct,
> >
> > My point is that to_char-ing intervals by converti
On Mon, 2002-06-10 at 15:56, Tom Lane wrote:
> Christoph Haller <[EMAIL PROTECTED]> writes:
> > Based on an entry in the mailing list from 30 Oct 2001
> > about efficient deletes on subqueries,
> > I've found two ways to do so (PostgreSQL 7.2.1):
> > ...
> > Is there a way to put the second for
On Tue, 2002-06-11 at 09:34, Karel Zak wrote:
> On Mon, Jun 10, 2002 at 07:18:44PM +0200, Hannu Krosing wrote:
>
> OK, I add to_interval() to may TODO (but it's unsure for 7.3).
>
> > hannu=# select to_char('33s 15h 10m 5months'::interval, '.MM.D
On Tue, 2002-06-11 at 04:53, Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Hannu Krosing wrote:
> > >> What about
> > >>
> > >> DELETE relation_expr FROM relation_expr [ , table_
On Tue, 2002-06-11 at 11:31, Karel Zak wrote:
> On Tue, Jun 11, 2002 at 12:37:09PM +0400, Fduch the Pravking wrote:
>
> > And 'DD' is defined as in range 1..31...
> > What if I try to select '100 days'?
> >
> > fduch=> SELECT to_char('100days'::interval, '-MM-DD HH24:MI:SS');
> >to_
On Tue, 2002-06-11 at 11:21, Karel Zak wrote:
> On Tue, Jun 11, 2002 at 11:16:13AM +0200, Hannu Krosing wrote:
> > On Tue, 2002-06-11 at 09:34, Karel Zak wrote:
>
> > > I think, we can keep this behaviour for to_char(), the good thing
> > > is that you can forma
On Tue, 2002-06-11 at 18:36, Josh Berkus wrote:
> Karel,
>
> > The to_interval() will have another (you wanted) behaviour.
>
> Please, please, please do not use to_interval for text formatting of
> intervals.
If he meant what _I_ described then this was exactly that, i.e.
converting (string,
On Wed, 2002-06-12 at 19:38, Tom Lane wrote:
> David Ford <[EMAIL PROTECTED]> writes:
> > So reentrancy in libpq basically is put on hold until 7.3.
>
> Only if you insist on using "crypt", which is deprecated anyway.
> md5 is the preferred encryption method.
>
> My feeling about the proposed pa
On Thu, 2002-06-13 at 03:47, Christopher Kings-Lynne wrote:
> > > What is a TRUNCATE TABLE but a drop create anyway? Is there some
> > > technical difference?
> > >
> > It doesn't kill indexes/triggers/constraints/Foreign Key Stuff, etc.
>
> Hrm - last time I checked it did...
Two questions :
On Fri, 2002-06-14 at 02:10, David Ford wrote:
> ... while talking to sss.pgh.pa.us.:
>
> >> MAIL From:<[EMAIL PROTECTED]>
> >>>
> >>>
> <<< 550 5.7.1 Probable spam from 68.9.71.221 refused - see
>http://www.five-ten-sg.com/blackhole.php?68.9.71.221
> 554 5.0.0 Service unavailable
>
>
On Thu, 2002-06-27 at 02:10, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Perhaps it wouldn't be such a terrible idea after all to store the casting
> > paths separately, such as in a system table pg_cast (from, to, func,
> > implicit). This would implement the SQL99 spec fa
On Fri, 2002-06-28 at 03:21, Josh Berkus wrote:
>
> Karel,
>
> >
> > OO in PostgreSQL means that you can create own operators, datetypes,
> functions...
>
> Last I checked, all of these things were part of the SQL spec. I believe our
> only "OO" functionality is inheritance ...
Actually
On Mon, 2002-07-01 at 09:47, Christopher Kings-Lynne wrote:
> Hi All,
>
> I've been thinking about this DROP COLUMN business (sorry to start another
> spammy, flamey thread!). I'm taking ideas from lots of sources here.
>
> How does this sound for a process?
>
> 1.
> A new column is added to p
On Tue, 2002-07-02 at 03:25, David M. Kaplan wrote:
> Hi,
>
> Has anyone considered creating an aggregate function that returns an
> array of all matching rows?
check contrib/intagg for a function that does it for integers.
---
Hannu
---(end of broadcast)---
On Wed, 2002-07-03 at 08:20, Christopher Kings-Lynne wrote:
> > Of course, a shared memory system probably is going to either do it
> > sequentailly or have its own index issues, so I don't see a huge
> > advantage to going to shared memory, and I do see extra code and a queue
> > limit.
>
> Is a
On Tue, 2002-07-02 at 23:35, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Is disk i/o a real performance
> > penalty for notify, and is performance a huge issue for notify anyway,
>
> Yes, and yes. I have used NOTIFY in production applications, and I know
> that performance is
On Tue, 2002-07-02 at 21:50, Lamar Owen wrote:
> On Tuesday 02 July 2002 03:14 pm, Jan Wieck wrote:
> > Lamar Owen wrote:
> > > [...]
> > > Martin O has come up with a 'pg_fsck' utility that, IMHO, holds a great
> > > deal of promise for seamless binary 'in place' upgrading. He has been
> > > abl
On Wed, 2002-07-03 at 14:32, Rod Taylor wrote:
> > > It should also be noted that an ALTER TABLE / SET TYPE implemented with
> > > the above idea with run into the 2x diskspace issue as well as take
> > > quite a while to process.
> >
> > I think that if the 'SET TYPE' operation is ever to be rol
On Wed, 2002-07-03 at 15:51, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > Are you planning to have one circular buffer per listening backend ?
>
> No; one circular buffer, period.
>
> Each backend would also internally buffer notifies that it ha
On Wed, 2002-07-03 at 16:30, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > There could a little more smartness here to avoid unneccessary copying
> > (not just storing) of not-listened-to data.
>
> Yeah, I was wondering about that too.
>
>
On Wed, 2002-07-03 at 16:30, Tom Lane wrote:
> My guess is that the actual volume of data going through the notify
> mechanism isn't going to be all that large, and so avoiding one memcpy
> step for it isn't going to be all that exciting.
It may become large if we will have an implementation whi
On Wed, 2002-07-03 at 17:28, Bruce Momjian wrote:
> Hannu Krosing wrote:
> > > Our very extensibility is our weakness for upgrades. Can it be worked around?
> > > Anyone have any ideas?
> >
> > Perhaps we can keep an old postgres binary + old backend around a
On Wed, 2002-07-03 at 17:48, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > but we are already attracting a thundering herd by
> > sending a signal to all _possibly_ interested backends at the same time
>
> That's why it's so important that
On Wed, 2002-07-03 at 22:43, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > On Wed, 2002-07-03 at 17:48, Tom Lane wrote:
> >> That's why it's so important that the readers use a sharable lock. The
> >> only thing they'd be lo
On Tue, 2002-07-09 at 00:20, Jan Wieck wrote:
> Zeugswetter Andreas SB SD wrote:
> >
> > > No, what I envisioned was a standalone dumper that can produce dump output
> > > without having a backend at all. If this dumper knows about the various
> > > binary formats, and knows how to get my data i
On Tue, 2002-07-09 at 03:47, Tatsuo Ishii wrote:
> > An aside: I was thinking about this some, from the PoV of using our
> > existing type system to handle this (as you might remember, this is an
> > inclination I've had for quite a while). I think that most things line
> > up fairly well to allow
701 - 800 of 1838 matches
Mail list logo
