On Sat, 16 Aug 2003, Joe Conway wrote:
> I stumbled across this behavior today and it seems strange if not a bug:
>
> -- this seems wrong
> vsconf=# create table foo (f1 char(1));
> CREATE TABLE
> vsconf=# insert into foo values(' ');
> INSERT 9002011 1
> vsconf=# select ascii(f1) from foo;
> as
Joe Conway <[EMAIL PROTECTED]> writes:
> I stumbled across this behavior today and it seems strange if not a bug:
ascii() is defined as ascii(text). As of 7.4, bpchar->text conversion
strips trailing blanks, so what ascii() sees is a zero-length string.
Given that trailing blanks are insignifica
On Sun, 17 Aug 2003, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > Basically, the first thing I noticed was that changing reltuples
> > on the pg_class row for a table affected the speed of
> > explain analyze select * from othertable where foo not in (select bar from
> > table)
Tom Lane wrote:
ascii() is defined as ascii(text). As of 7.4, bpchar->text conversion
strips trailing blanks, so what ascii() sees is a zero-length string.
That makes sense -- I was wondering where the blanks got stripped.
Given that trailing blanks are insignificant in bpchar, I'm not sure I'd
c
> > > > auth.c: In function `pg_krb5_recvauth':
> > > > auth.c:294: structure has no member named `user'
> > >
> > > Ooops, my fault --- I didn't build with Kerberos support after
> > > changing those field names.
> > >
> > > Now that I think about it, there might be similar omissions in the
> >
On Sun, 17 Aug 2003, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> >> with reltuples=1000 for pktest, query takes about 96 seconds
> >> reltuples=1, query takes about 15 seconds
> >> reltuples=10, query takes about 8 seconds
>
> > Errm, I meant in the cases where it still
Added to HISTORY:
New pg_get_triggerdef(prettyprint) and pg_constraint_is_visible() functions
---
Christopher Kings-Lynne wrote:
> I think the new pg_get_triggerdef and pg_constraint_is_visible functions
> aren't mention
Added to TODO:
* Allow PREPARE of cursors
---
Tom Lane wrote:
> Sean Chittenden <[EMAIL PROTECTED]> writes:
> >> I'm beginning to think that was a serious omission. I'm tempted to
> >> fix it, even though we're pa
Stephan Szabo <[EMAIL PROTECTED]> writes:
> Basically, the first thing I noticed was that changing reltuples
> on the pg_class row for a table affected the speed of
> explain analyze select * from othertable where foo not in (select bar from
> table);
> even when the plan wasn't changing, seqscan +
Is there a TODO here? Text?
---
Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > What do you actually get back from a Parse request?
>
> Nothing. If successful, it creates a prepared statement ins
I stumbled across this behavior today and it seems strange if not a bug:
-- this seems wrong
vsconf=# create table foo (f1 char(1));
CREATE TABLE
vsconf=# insert into foo values(' ');
INSERT 9002011 1
vsconf=# select ascii(f1) from foo;
ascii
---
0
(1 row)
-- this is what I'd expect
vsco
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Sun, 17 Aug 2003, Bruce Momjian wrote:
>> Is this a bug?
> I don't think so. I'd say this is the expected behavior. Part of the
> point is that it fails without checking for matching rows.
To do anything else, you'd have to solve some locking and/or
On Sun, 17 Aug 2003, Bruce Momjian wrote:
> Is this a bug?
I don't think so. I'd say this is the expected behavior. Part of the
point is that it fails without checking for matching rows.
> Robert Treat wrote:
> > On Mon, 2003-08-04 at 12:19, Tom Lane wrote:
> > > Bruce Momjian <[EMAIL PROTECTE
Stephan Szabo <[EMAIL PROTECTED]> writes:
>> with reltuples=1000 for pktest, query takes about 96 seconds
>> reltuples=1, query takes about 15 seconds
>> reltuples=10, query takes about 8 seconds
> Errm, I meant in the cases where it still chose a hashed
> subplan. Stupid cold medicine.
I
Added to TODO:
o Allow pooled connections to query prepared queries
o Allow pooled connections to close all open WITH HOLD cursors
---
Neil Conway wrote:
> On Fri, Aug 08, 2003 at 04:00:22PM -0400, Tom Lane
I assume this has been addressed?
---
Neil Conway wrote:
> I'm working on writing a script that automatically tests all the
> built-in functions. As a first step, I just passed NULL for all
> of the arguments for each built-
Added to TODO:
* Add ALTER DOMAIN, AGGREGATE, CONVERSION, SEQUENCE ... OWNER TO
---
Andreas Pflug wrote:
> Tom Lane wrote:
>
> >"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> >
> >
> >>But should the CR
Is this a bug?
---
Robert Treat wrote:
> On Mon, 2003-08-04 at 12:19, Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > This this a TODO? Keep in mind if we follow the syntax of VACUUM and
> > > (7.4) CLUS
Added to TODO:
* Add TRUNCATE ... CASCADE
---
Josh Berkus wrote:
> Guys,
>
> > I wouldn't care for that either. The prior suggestion of "TRUNCATE tab
> > CASCADE" (to truncate any tables with FK dependencies on t
On Sat, 16 Aug 2003, Stephan Szabo wrote:
>
> I've noticed that when the stats are wrong (like
> in cases where you've loaded data but reltuples
> hasn't been updated yet) that a hashed NOT IN
> seems to take a significant time penalty. Is
> this to be expected?
>
> On a pktest table with 1 mill
I've noticed that when the stats are wrong (like
in cases where you've loaded data but reltuples
hasn't been updated yet) that a hashed NOT IN
seems to take a significant time penalty. Is
this to be expected?
On a pktest table with 1 million integers and a dual table with a single
integer and so
Has this been addressed?
---
Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > Presumably, the "is_superuser" parameter was intended to make the updating
> > of psql's prompt more accurate when SET SESSION A
Oh, removed.
---
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I have added this email to CVS as src/tools/error_text. Any changes to
> > it?
>
> Waste of CVS space; the real documentation is in SGML:
> h
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I have added this email to CVS as src/tools/error_text. Any changes to
> it?
Waste of CVS space; the real documentation is in SGML:
http://developer.postgresql.org/docs/postgres/error-style-guide.html
regards, tom lane
I have added this email to CVS as src/tools/error_text. Any changes to
it?
---
Tom Lane wrote:
> I'm about to start going through the backend's elog() calls to update
> them to ereport() style, add error code numbers, polis
Sean Chittenden wrote:
> > > auth.c: In function `pg_krb5_recvauth':
> > > auth.c:294: structure has no member named `user'
> >
> > Ooops, my fault --- I didn't build with Kerberos support after
> > changing those field names.
> >
> > Now that I think about it, there might be similar omissions in
Are these IPv6 deficiencies addressed?
---
Tom Lane wrote:
> The IPv6 patch seems to still be a few bricks shy of a load. Grepping
> for places that handle AF_INET but not AF_INET6 revealed these
> unimplemented features:
>
A long time ago, in a galaxy far, far away, [EMAIL PROTECTED] (ivan) wrote:
> Can you add LIKE TO CREATE TYPE too ? There could be
> also CREATE TYPE ble AS ( LIKE CREATE TABLE ble ( LIKE ) , and each colmnu from compose
> type will be add to table "ble" with static (NOT) NULL, and without
> de
On Saturday 16 August 2003 13:52, Andrew Dunstan wrote:
> [EMAIL PROTECTED] andrew]# rpm --test -Uhv postgresql-*7.3.4-1PGDG.*.rpm
> error: Failed dependencies:
> perl(Pg) is needed by postgresql-contrib-7.3.4-1PGDG
> [EMAIL PROTECTED] andrew]#
> [EMAIL PROTECTED] andrew]# rpm -q --whatpro
It looks like that right now if you have multiple constraints
with the same name on different tables and some are deferrable
and some are not, SET CONSTRAINTS "name" DEFERRED will fail when
it reaches the not deferrable constraint. Is this the behavior
we want, or do we want it to defer the deferr
This time it's on RH8.
The distributed RPMs complain thus:
[EMAIL PROTECTED] andrew]# rpm --test -Uhv postgresql-*7.3.4-1PGDG.*.rpm
error: Failed dependencies:
perl(Pg) is needed by postgresql-contrib-7.3.4-1PGDG
[EMAIL PROTECTED] andrew]#
Strangely enough, I look for it and see this:
[EM
The original patch added rpath only for libpq and a few other places.
Larry, I think you should submit a patch that follows what HPUX does. I
think you only need to modify the unixware portion of Makefile.shlib. I
think the original objection was having to put stuff in libpq/Makefile.
---
Sounds good to me too.
---
Joe Conway wrote:
> Tom Lane wrote:
> > Today it occurred to me that we could look in pg_opclass for a default
> > btree opclass for the datatype. If we find one, then the Equal and Less
> > membe
I have applied a patch to have NEED_REENTRANT_FUNC_NAMES _require_ the
*_r libraries, rather than the old behavior of just using the *_r
libraries if they exist. With my new research documented in thread.c, I
think this is the proper way to handle it.
I have also marked FreeBSD as not requiring
Can you add LIKE TO CREATE TYPE too ?
There could be also CREATE TYPE ble AS ( LIKE ) , and each colmnu from compose
type will be add to table "ble" with static (NOT) NULL, and without
defaults.
what do you think ?
---(end of broadcast)---
TIP 3:
David Fetter <[EMAIL PROTECTED]> writes:
> [code]
Seems pretty messy. I believe the standard way of doing this is
regression=# create function epoch_to_timestamp(float8) returns timestamptz as '
regression'# begin
regression'# return ''epoch''::timestamptz + $1 * ''1 second''::interval;
regres
Larry Rosenman <[EMAIL PROTECTED]> writes:
> Has the idea of putting the infrastructure in place to allow a full pathname
> to be fed to DT_SONAME been totally killed?
What makes you think you need new infrastructure? The HPUX port has
used a full-path rpath for years.
re
37 matches
Mail list logo
