"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> I am still hopeful that we can get a significant plperl improvement before
> feature freeze, including shared data space, set returning funcs,
> composite returning funcs, triggers and an spi query mechanism. It will be
> touch and go and we might not
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> Perhaps we should think about creating a shared version of
>> pg_description so we could have more reasonable support for comments
>> on shared objects. I'm not in a hurry for this but it would be a
>> reasonable TODO item.
> Just add a comme
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> ERROR: tablespace 292909 has been deleted
> How about "schema default tablespace 292909 has been deleted"?
Yeah, I was wondering if we could finger the specific schema that
was causing the problem, but the place that would detect the error
co
Bruce Momjian said:
> We have twelve days until July 1, feature freeze.
>
> Looking at our list:
>
> Win32 - need service manger code, installer is outside project
>
> Tablespaces - patch installed; discussing implementation and
> administration details.
>
> Nested transactions - submitted, with p
ERROR: tablespace 292909 has been deleted
How about "schema default tablespace 292909 has been deleted"?
Chris
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROT
Tom Lane said:
> "Dave Page" <[EMAIL PROTECTED]> writes:
>> I'm getting the following error when trying to initdb with CVS tip.
>
>> creating template1 database in C:/msys/1.0/local/pgsql/data/base/1 ...
>> ERROR: could not open segment 1 of relation 1663/1/1255 (target block
>> 26189776): No such
Well, it has the same issues as COMMENT ON DATABASE, which we support,
though crudely.
Perhaps we should think about creating a shared version of
pg_description so we could have more reasonable support for comments
on shared objects. I'm not in a hurry for this but it would be a
reasonable TODO it
Actually, this is the current state of this issue.
---
Andreas Pflug wrote:
> Tom Lane wrote:
>
> >Andreas Pflug <[EMAIL PROTECTED]> writes:
> >
> >
> >>>Answering my own question, the distribution of the current logfile
Is there a TODO here? No one explained why frozen tuples are important.
---
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > On 6/12/2004 3:45 PM, Tom Lane wrote:
> >> I don't think it would help very much to def
We have twelve days until July 1, feature freeze.
Looking at our list:
Win32 - need service manger code, installer is outside project
Tablespaces - patch installed; discussing implementation and
administration details.
Nested transactions - submitted, with phantom xids; only needs trigger
and
Were are we on this?
---
Andreas Pflug wrote:
> Tom Lane wrote:
>
> >
> >This has got portability issues (fopen("ab"))
> >
> My doc says b is ignored on ansi systems, and recommends using it. Do
> you have other experience
Where are we on this?
---
Tom Lane wrote:
> Manfred Koizar <[EMAIL PROTECTED]> writes:
> > I understand you, honestly. Do I read between your lines that you
> > didn't review my previous vacuum.c refactoring patch? Please
On Fri, 18 Jun 2004, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > If we just wanted to make the error message more user friendly, perhaps we
> > could *gulp* store the tablespace name in PG_VERSION.
>
> That's actually not a bad idea from a debugging standpoint. But I don't
> se
Gavin Sherry <[EMAIL PROTECTED]> writes:
> If we just wanted to make the error message more user friendly, perhaps we
> could *gulp* store the tablespace name in PG_VERSION.
That's actually not a bad idea from a debugging standpoint. But I don't
see that it helps any for this particular problem.
On Fri, 18 Jun 2004, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > Is it really that bad? NamespaceCreate() could just touch a file at
> > pg_tablespaces/// and
> > RemoveSchema() could remove it.
>
> No, because that wouldn't be rollback-safe. You'd have to make the
> placeholde
Gavin Sherry <[EMAIL PROTECTED]> writes:
> Is it really that bad? NamespaceCreate() could just touch a file at
> pg_tablespaces/// and
> RemoveSchema() could remove it.
No, because that wouldn't be rollback-safe. You'd have to make the
placeholder file act enough like a real relation that the smg
On Fri, 2004-06-18 at 08:24, Chris Browne wrote:
> "Santo Quartarone" <[EMAIL PROTECTED]> writes:
> > What's the safest email browser?
>
> less is pretty safe, more or less ;-).
>
> You didn't specify what sort of platform you wanted to use; the
> choices vary, considerably, between platforms.
I
On Fri, 18 Jun 2004, Tom Lane wrote:
> Although DROP TABLESPACE can detect tables existing in the target
> tablespace, it doesn't have any way to detect schemas that reference
> that tablespace as their default tablespace. Thus you can get
> implementation-level failures like this one:
>
Of cour
Although DROP TABLESPACE can detect tables existing in the target
tablespace, it doesn't have any way to detect schemas that reference
that tablespace as their default tablespace. Thus you can get
implementation-level failures like this one:
$ mkdir /tmp/junk
regression=# create tablespace junk
"Santo Quartarone" <[EMAIL PROTECTED]> writes:
> What's the safest email browser?
less is pretty safe, more or less ;-).
You didn't specify what sort of platform you wanted to use; the
choices vary, considerably, between platforms.
--
(format nil "[EMAIL PROTECTED]" "cbbrowne" "cbbrowne.com")
ht
Quoth [EMAIL PROTECTED] (Bruce Momjian):
> Andrew Sullivan wrote:
>> On Thu, Jun 17, 2004 at 01:12:10PM -0400, Bruce Momjian wrote:
>>
>> > Well, the bad news is that this backtrace isn't very useful.
>>
>> No kidding. It's pretty frustrating.
>>
>> > My only guess is that getaddrinfo in your
"Dave Page" <[EMAIL PROTECTED]> writes:
> I'm getting the following error when trying to initdb with CVS tip.
> creating template1 database in C:/msys/1.0/local/pgsql/data/base/1 ...
> ERROR: could not open segment 1 of relation 1663/1/1255 (target block
> 26189776): No such file or directory
Th
At 2004-06-18 13:11:19 -0400, [EMAIL PROTECTED] wrote:
>
> > Would anyone be interested in a patch to allow this?
>
> Yes, but not the way you suggest. The ... approach forces calling
> code to know *when it is written* how many result columns there will
> be, because you'd have to actually write
I'm getting the following error when trying to initdb with CVS tip. This
is on win XP, though I don't know if it's win32 specific. Also of note,
although it says it's clearing the contents of the directory, in actual
fact it leaves the directory structure in place, thus a subsequent
initdb will not
Mark (see I remembered your name), where are we on this patch? It needs
docs and include has to be redone. Should I remove the include part of
the patch, add docs, and apply it?
---
[EMAIL PROTECTED] wrote:
> >
> > Where a
Hello:
Depends whether you built the server with --enable-integer-timestamps
or not.
Thanks :)
Sure: don't use binary I/O.
hehe ... :-\ i will do ... thanks again :)
--
Best regards
Carlos Guzmán Álvarez
Vigo-Spain
---(end of broadcast)---
TIP
=?ISO-8859-1?Q?Carlos_Guzm=E1n_=C1lvarez?= <[EMAIL PROTECTED]> writes:
> What is the supposed format that should be expected for time and
> timestamp values in binary format ??
Depends whether you built the server with --enable-integer-timestamps
or not.
> There are any way to retrieve the value
Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
Comment on TABLESPACE is impossible, no? Tablespaces are a global
relation and pg_description isn't.
Well, it has the same issues as COMMENT ON DATABASE, which we support,
though crudely.
Perhaps we should think about cre
Hello:
A user of the PgSqlClient ADO.NET provider is having problems
when with timestamp and time values, he has a postgres 7.4.1
postgres install in a Suse machine.
The provider works implements v3.0 of the postgres protocol handling
timestamp andtime in binary format, the problem seems to be that
Abhijit Menon-Sen <[EMAIL PROTECTED]> writes:
> The documentation for PQexecPrepared says:
> (There is not currently a provision to obtain different result
> columns in different formats, although that is possible in the
> underlying protocol.)
> Would anyone be interested in a patch t
Shachar Shemesh <[EMAIL PROTECTED]> writes:
> I have defined a datatype called "varcharci", shamelessly yanking the
> input, output, recv and send functions from varchar. This means (as far
> as I understand things) that this type is binary compatible with varchar.
Use text, not varchar.
> Why
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Shachar Shemesh wrote:
>> According to the docs, domains are not meant for that purpose, but
>> for changing constraints of a type. Is it possible to define a domain
>> that will have the same defaults and constraints as the base type,
>> but will have
Thanks (again) Tom, I'll try to do as You suggested.
I was poking around backend libpq, but was unable to find where exactly
that information is prepared and send to libpq buffer.
Regards !
- Original Message -
From: "Tom Lane" <[EMAIL PROTECTED]>
To: "Darko Prenosil" <[EMAIL PROTECTED]>
joseph speigle <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] pgsql]$ initdb --locale=ko_KR --lc-messages=C -E unicode -D
> `pwd`/unidata
Is that a valid combination of locale and encoding? The locale setting
implies a particular encoding, but unfortunately Postgres has no way to
tell which one
The documentation for PQexecPrepared says:
(There is not currently a provision to obtain different result
columns in different formats, although that is possible in the
underlying protocol.)
Would anyone be interested in a patch to allow this?
I could, for example, change PQsendQuery
Darko Prenosil <[EMAIL PROTECTED]> writes:
> What is SPI equivalent for libpq PQftable & PQFtablecolumn functions ?
There is none. SendRowDescriptionMessage gets the column ID info by
rooting around in the targetlist of the SELECT query, and you'd have
to do the same.
Hi!
since we have a lot of databases here that suffer from pg_dump's
deficits in 7.3 and 7.4 regarding dependencies, we tried pg_dump from
the upcoming 7.5 release.
This version works much better, but it is not possible to dump a
complete cluster using pg_dumpall in a 7.3 or 7.4 compatible way b
Mark Gibson <[EMAIL PROTECTED]> writes:
> Is there any reason that the following shouldn't work:
> CREATE TABLE my_new_table (LIKE my_composite_type);
Probably not. I can think of reasons why we might not want to let you
INHERIT from a composite type, but LIKE is just a one-time copy-the-
row-de
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Comment on TABLESPACE is impossible, no? Tablespaces are a global
> relation and pg_description isn't.
Well, it has the same issues as COMMENT ON DATABASE, which we support,
though crudely.
Perhaps we should think about creating a shared ver
First time I posted a question using complicated example, but this time I'll
be wiser and simplify the question:
What is SPI equivalent for libpq PQftable & PQFtablecolumn functions ?
Regards !
---(end of broadcast)---
TIP 6: Have you se
On Thu, Jun 17, 2004 at 06:06:12PM -0400, Bruce Momjian wrote:
>
> When you say "init" directory, what do you mean? /bin?
No. The place where the init scripts (which cause postgres to start)
live.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
In the future this spectacle of the middle classes sh
Hi,
Is there any reason that the following shouldn't work:
CREATE TABLE my_new_table (LIKE my_composite_type);
I get the following error (in 7.4.2):
ERROR: "my_composite_type" is a composite type
With the improved handling of composite types,
will this work in 7.5?
Cheers
--
Mark Gibson
Web De
> > My only guess is that getaddrinfo in your libc has a bug somehow that is
> > corrupting the stack (hance the improper backtrace), then crashing.
>
> It could be libc on AIX, I suppose, but it strikes me as sort of odd
> that nobody else ever seens this. Unless nobody else is using AIX
> 5.1,
43 matches
Mail list logo