> Any objection if I rework this function to meet SQL92 and fix the bug?
I don't object.
> Or is the SQL92 part not desirable because it breaks backward
> compatability?
I don't think so.
> In any case, can the #ifdef MULTIBYTE's be removed now in favor of a
> test for encoding max length?
Ralph Graulich wrote:
>Hi,
>
>just my two cents worth: I like having the files sized in a way I can
>handle them easily with any UNIX tool on nearly any system. No matter
>wether I want to cp, tar, dump, dd, cat or gzip the file: Just keep it at
>a maximum size below any limits, handy for handlin
Lamar Owen wrote:
>
>And you added this by doing what, exactly? I'm not familiar with pg_dump
>largefile support as a standalone feature.
>
Enabling largefile support for the utilities was accomplished by :
CFLAGS="-O2 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" ./configure ...
It seemed to
Gavin Sherry <[EMAIL PROTECTED]> writes:
> As for your question (and, perhaps, SQL99) I don't seen how it makes any
> sense to specify ON COMMIT outside of a transaction block.
Surely it does.
CREATE TEMP TABLE foo(...) ON COMMIT DELETE ROWS;
BEGIN;
insert some rows in f
Tom Lane wrote:
> I was wondering about that too, in particular: what name are you going
> to give to the implicit type, and what if it conflicts?
>
> The already-accepted mechanism for anonymous function-result types for
> RECORD functions doesn't have that problem, because it has no need to
> c
Joe Conway wrote:
> more work than I had time for when I wrote the current replace(). But as
> I said, if there is support for getting this into the backend, I'll add
> it to my todo list:
>
> - Create new backend function replace()
> - Either create new backend functions, or merge into existin
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
> Here's my thoughts on the matter:
> More than one period throws an error (something pleasant, mentioning
> that we do not quite support cross-database queries yet).
The just-committed implementation doesn't throw an error, but silently
discards
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Joe Conway writes:
>> 3. Modify CREATE FUNCTION to allow the implicit creation of a dependent
>> composite type, e.g.:
> Forgive this blunt question, but: Why?
> Of course I can see the answer, it's convenient, but wouldn't the system
> be more con
"Greg Sabino Mullane" <[EMAIL PROTECTED]> writes:
>> we'd write something like
>> select ... from pg_class p, ...
>> where relname like 'foo%' and pg_relation_is_visible(p.oid) and ...
> I see what you are saying, and this is fine for those cases in which the user
> has supplied the schema, but
Thomas Lockhart wrote:
> > Thomas, would you remind me of the concusions because I thought everyone
> > involved felt that it should be an initdb-only option, but I still see
> > it in CVS.
>
> ?? "Concussions" as in brain bruises? ;)
Uh, conclusions. Sorry. New keyboard desk in new house. :-)
Joe Conway wrote:
> Thomas Lockhart wrote:
> >>That's what I was thinking. In cases where you want to use the type for
> >>several functions, use CREATE TYPE. If you only need the type for one
> >>function, let the function creation process manage it for you.
> >
> > It would be nice then to have
OK, let's get started updating all our db access routines. We only have
22 days left until beta.
---
Joe Conway wrote:
> Greg Sabino Mullane wrote:
> > At any rate, I will play with the RelationIsVisible stuff when somebod
> Thomas, would you remind me of the concusions because I thought everyone
> involved felt that it should be an initdb-only option, but I still see
> it in CVS.
?? "Concussions" as in brain bruises? ;)
I'm not sure I understand the question. I assume that we are talking
about the WAL log locatio
Your patch has been added to the PostgreSQL unapplied patches list at:
http://candle.pha.pa.us/cgi-bin/pgpatches
I will try to apply it within the next 48 hours.
---
Teodor Sigaev wrote:
> Fixed very stupid but i
Thomas, would you remind me of the concusions because I thought everyone
involved felt that it should be an initdb-only option, but I still see
it in CVS.
---
Thomas Lockhart wrote:
> > Thomas, have you commented on the obj
Tom Lane wrote:
> "J. R. Nield" <[EMAIL PROTECTED]> writes:
> >> Uh, why? Why not just force a checkpoint and remember the exact
> >> location of the checkpoint within the current log file?
>
> > If I do a backup with PITR and save it to tape, I need to be able to
> > restore it even if my machi
Thomas Lockhart wrote:
>>That's what I was thinking. In cases where you want to use the type for
>>several functions, use CREATE TYPE. If you only need the type for one
>>function, let the function creation process manage it for you.
>
> It would be nice then to have some mechanism for converting
> That's what I was thinking. In cases where you want to use the type for
> several functions, use CREATE TYPE. If you only need the type for one
> function, let the function creation process manage it for you.
It would be nice then to have some mechanism for converting the
"automatic type" to a
Hi,
We recently put up a new 7.2.1 installation on Solaris 8 that serves a
24x7 e-commerce site. The system seems to run pretty well most of the
time but we see a consistent form of performance anomaly.
Watching pg_stat_activity the system spends most of it's time running
smoothly with queries c
Thank you, we figured out that, the query with lower() is taking too long
and we thought it is having some problem. The actual table in our database
has more than 10 million rows and query is taking too long.
Thanks
Yuva
-Original Message-
From: Yuva Chandolu
Sent: Friday, August 09, 2
> > Is it likely to have more than one function using a complex type like
> > that? If not, then allowing it's creation (not enforcing) could be
> > useful.
>
> That's what I was thinking. In cases where you want to use the type for
> several functions, use CREATE TYPE. If you only need the ty
On Fri, 9 Aug 2002, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > template1=# create temp table a (a int) on commit drop;
> > ERROR: You must be inside a transaction to use ON COMMIT
>
> Surely that's only for ON COMMIT DROP, if you intend to offer the
> others?
I should have
> -Original Message-
> From: Joe Conway [mailto:[EMAIL PROTECTED]]
> Sent: Friday, August 09, 2002 4:04 PM
> To: Peter Eisentraut
> Cc: pgsql-hackers
> Subject: Re: [HACKERS] Proposal: stand-alone composite types
>
>
> Peter Eisentraut wrote:
> > Joe Conway writes:
> >>3. Modify CREATE
Rod Taylor wrote:
> I think it buys the same as SERIAL does for sequences.
That's a great analogy.
> Is it likely to have more than one function using a complex type like
> that? If not, then allowing it's creation (not enforcing) could be
> useful.
That's what I was thinking. In cases where y
I think it buys the same as SERIAL does for sequences.
Is it likely to have more than one function using a complex type like
that? If not, then allowing it's creation (not enforcing) could be
useful.
On Fri, 2002-08-09 at 19:03, Joe Conway wrote:
> Peter Eisentraut wrote:
> > Joe Conway writes
Peter Eisentraut wrote:
> Joe Conway writes:
>>3. Modify CREATE FUNCTION to allow the implicit creation of a dependent
>>composite type, e.g.:
>
> Forgive this blunt question, but: Why?
Now's a *great* time for a blunt question because I haven't started
actively working on this yet. Much b
Joe Conway writes:
> 3. Modify CREATE FUNCTION to allow the implicit creation of a dependent
> composite type, e.g.:
Forgive this blunt question, but: Why?
Of course I can see the answer, it's convenient, but wouldn't the system
be more consistent overall if all functions and types are dec
Greg Sabino Mullane wrote:
> At any rate, I will play with the RelationIsVisible stuff when somebody
> writes a SQL interface to it (or I write it myself, but that will take
> quite a long time :)
>
Looks like Tom just committed this; see:
http://developer.postgresql.org/cvsweb.cgi/pgsql-serv
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Here's my thoughts on the matter:
More than one period throws an error (something pleasant, mentioning
that we do not quite support cross-database queries yet).
I'll assume we are switching to the "explicit wildcard" system for this.
(I think th
Hi, We have a problem with lower() function working differently for two
different data types
table: yuva_test
column_name data_type
yt_name1varchar(255)
yt_name2char(1)
The data is
yt_name1yt_name2
yuvaF
bharat F
1234556 F
234 F
etc.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
(Moved from
Re: [PATCHES] small psql patch - show Schema name for \dt \dv \dS)
>> I need something other than RelationIsVisible for psql for the case
>> when someone says "\d foo" - I need to be able to decide which
>> "foo" table I should displ
Hi Florian,
Is it possible to crash a 7.2.1 backend without having an entry in the
pg_hba.conf file?
i.e. Is every PostgreSQL 7.2.1 installation around vulnerable to a
remote DoS (or worse) from any user anywhere, at this moment in time?
Regards and best wishes,
Justin Clift
Florian Weimer w
Florian Weimer <[EMAIL PROTECTED]> writes:
> Neil Conway <[EMAIL PROTECTED]> writes:
>
>> Thomas can correct me if I'm mistaken, but I believe these changes apply
>> to the new integer datetime code
>
> No, it's possible to crash the backend in 7.2, too.
And 7.2.1, of course.
Let me ask again:
Fixed very stupid but important bug: mixing calls of some founctions from
contrib/tsearch and contrib/ltree :)
--
Teodor Sigaev
[EMAIL PROTECTED]
patch_ltree.gz
Description: application/gzip
---(end of broadcast)---
TIP 6: Have you searched
Christopher Kings-Lynne wrote:
> Hi guys,
>
> If you apply the pg_stat_reset() function patch you get this regression
> failure. Is this because it's returning a bool I guess? Shall I just fix
> the regression test to exclude this function?
> AND p1.proname != 'update_pg_pwd_and_pg_g
Gavin Sherry <[EMAIL PROTECTED]> writes:
> template1=# create temp table a (a int) on commit drop;
> ERROR: You must be inside a transaction to use ON COMMIT
Surely that's only for ON COMMIT DROP, if you intend to offer the
others?
regards, tom lane
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> If you apply the pg_stat_reset() function patch you get this regression
> failure. Is this because it's returning a bool I guess? Shall I just fix
> the regression test to exclude this function?
No, you should fix the function definition.
I'm a little out of my league on this list, but I thought I might discuss a
problem I'm having since it seems to have come up here recently. I have read
the archives w/ respect to the inheritance mechanism, the problems with it,
etc. But I still think it would be a useful thing to have in Postgr
On Fri, 9 Aug 2002, Helge Bahmann wrote:
> > As far as I can make out from the libc docs, largefile support is
> > automatic if the macro _GNU_SOURCE is defined and the kernel supports
> > large files.
> >
> > Is that a correct understanding? or do I actually need to do something
> > special to
Attached is a revised version of my previous
ON COMMIT DROP
patch. This patch implements:
ON COMMIT { DROP | PRESERVE ROWS | DELETE ROWS }
The latter two are SQL99.
Sample usage:
---
template1=# begin;
BEGIN
template1=# create temp table a (a int) on commit drop;
CREATE
template1=# create tem
On Thu, Aug 08, 2002 at 11:19:04PM +0200, Peter Eisentraut wrote:
> It seems we need a smart plan for handling the decimal point vs. comma
> issue. Observe: (lc_numeric = de_DE)
^^
It seems like hellish toy... :-)
Karel
--
Karel Zak <[EMAIL PROTECTED
41 matches
Mail list logo
