Tom,
> On re-reading the thread, I'm more than a bit confused by this response.
> I thought you were suggesting that the top-level configure should have
> a simple option that says "please build and install all the contrib
> modules while you are at it". ÂRight now that requires a separate step
>
FWIW, I don't see the issue as "internal vs external" at all. What's
bothering me is whether these views can be considered sufficiently
more stable and better designed than the physical system catalogs
to justify recommending that application designers should rely on
the views instead of the catal
"Thomas F. O'Connell" <[EMAIL PROTECTED]> writes:
> I think it's important to consider the perspective of both developers
> and users, and the internal views clearly creates issues for the
> developers.
FWIW, I don't see the issue as "internal vs external" at all. What's
bothering me is wheth
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> First, I *really* wish we'd call it something else. Contrib conveys
>> "unsupported" to people.
> And that's exactly what it is supposed to mean. We say, these modules
> do not necessarily meet our standards with regard to c
I'm not thinking exclusively in terms of whether they would be useful
to me, personally. In fact, I'm certain that they would be useful to
me, personally.
What I question is whether they need to be a part of the internal
development of PostgreSQL. To me, CPAN is an integral part of being
a
Josh Berkus writes:
> Peter,
>> I don't see how this makes it any more user friendly or easier on
>> package builders. Is your aim to make building contrib more accessible
>> or building only specific contrib modules more accessible?
> Building specific contrib modules.
On re-reading the thread,
I suppose that we can't change the semantics of SQL_ASCII without
backwards compatibility problems. I wonder if introducing a new encoding
that only allows 7-bit ascii, and making that the default, is the way to
go.
A while back I requested a new encoding that is '7BITASCII'. It would
be excellen
The SQL_ASCII-breaks-JDBC issue just came up yet again on the JDBC list,
and I'm wondering if we can do something better on the server side to
help solve it.
The problem is that people have SQL_ASCII databases with non-7-bit data
in them under some encoding known only to a (non-JDBC) application.
Please check the web site version. Someone has already implemented
"Allow COPY to optionally include column headings in the first line".
As far as XML, there has been discussion on where that should be done?
In the backend, libpq, or psql. It will need discussion on hackers. I
assume you have r
Sergey Ten wrote:
> Hello all,
>
> We would like to contribute to the Postgresql community by implementing
> the following items from the TODO list
> (http://developer.postgresql.org/todo.php):
> . Allow COPY to understand \x as a hex byte . Allow COPY to optionally
> include column headings in
Hello all,
We would like to contribute to the Postgresql community by implementing
the following items from the TODO list
(http://developer.postgresql.org/todo.php):
. Allow COPY to understand \x as a hex byte . Allow COPY to optionally
include column headings in the first line . Add XML output
perhaps the CRC-32 routines could be written in in-line assembler
If you can do this, step right up. :-)
Best Regards, Simon Riggs
Surely there's an open source code floating around somewhere?
Chris
---(end of broadcast)---
TIP 4: Don't 'kill -9' the
Peter,
> I don't see how this makes it any more user friendly or easier on
> package builders. Is your aim to make building contrib more accessible
> or building only specific contrib modules more accessible?
Building specific contrib modules.
--
--Josh
Josh Berkus
Aglio Database Solutions
Sa
Josh Berkus wrote:
> What if we could build contrib modules through a build-time switch
> for PostgreSQL? Like,
>
> ./configure --with-perl --with-dblink --with-newsysviews
>
> This would seem a *lot* more user friendly to me, and easier on the
> package builders. What's the technical obstacle t
Andrew Dunstan wrote:
> First, I *really* wish we'd call it something else. Contrib conveys
> "unsupported" to people.
And that's exactly what it is supposed to mean. We say, these modules
do not necessarily meet our standards with regard to code quality,
portability, user interfaces, internati
On 5/11/05, Juan Pablo Espino <[EMAIL PROTECTED]> wrote:
> Hello all
>
> I have been studying the rule system in Postgres. I understand that
> the original query tree is the input at the rewrite, and then this
> query tree is modified by the rewrite in case that there is a rule.
>
> SQL query --
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Josh Berkus wrote:
What if we could build contrib modules through a build-time switch for
PostgreSQL? Like,
I honestly don't see that it buys a lot. (and the technical obstacle is
that there's a maintenance cost, if n
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Josh Berkus wrote:
>>What if we could build contrib modules through a build-time switch for
>>PostgreSQL? Like,
> I honestly don't see that it buys a lot. (and the technical obstacle is
> that there's a maintenance cost, if nothing else).
I'm with
On Wed, May 11, 2005 at 02:55:46PM -0700, Josh Berkus wrote:
> > First, I *really* wish we'd call it something else. Contrib conveys
> > "unsupported" to people. Maybe we should call it "modules" or something
> > like that.
> Agreed.
Ditto
> > I honestly don't see that it buys a lot. (and the tech
Josh Berkus writes:
>> - The superuser only generic file functions in the admin package have
>> been posted for 8.0, but where (more or less ) silently dropped. These
>> functions allow pgadmin to display the server logs, as well as editing
>> pg_hba.conf and postgresql.conf without console access
On Wed, May 11, 2005 at 02:41:43PM -0700, elein wrote:
> Adding to the ambiguity is the dot notation used for
> composite columns. Don't forget the other end ignoring
> those required parens.
>
> is foo.bar.zap
> a database.schema.table
> a schema.table.column
> a table.column
On Wed, May 11, 2005 at 05:43:32PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > On Wed, May 11, 2005 at 05:28:22PM -0400, Tom Lane wrote:
> >> No, actually, I was wondering where the potentially N levels of schema
> >> names would appear in the output ...
>
> > My immedi
Jim C. Nasby wrote:
On Wed, May 11, 2005 at 02:34:21PM -0700, Joshua D. Drake wrote:
I could see --with-contrib but other than that... there are ALOT of
packages in contrib.
I'm not configure expert, but I think it wouldn't be hard to do
something like --with-contrib='module1 module2 module3'. I
On 2005-05-11, "Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
> On Wed, May 11, 2005 at 04:44:21PM +, Andreas Pflug wrote:
>> There's still a lengthy discussion going on whether it's a good idea to
>> add a forth way to read pgsql's schema (pg_* tables, pg_* views,
>> information_schema, did I mis
Andrew,
> First, I *really* wish we'd call it something else. Contrib conveys
> "unsupported" to people. Maybe we should call it "modules" or something
> like that.
Agreed.
> I honestly don't see that it buys a lot. (and the technical obstacle is
> that there's a maintenance cost, if nothing els
Josh Berkus wrote:
Folks,
Hey, I can see a way for /contrib to become a lot better option for
stuff-we're-not-sure-whether-to-include.
First, I *really* wish we'd call it something else. Contrib conveys
"unsupported" to people. Maybe we should call it "modules" or something
like that.
What
On Wed, May 11, 2005 at 02:34:21PM -0700, Joshua D. Drake wrote:
> I could see --with-contrib but other than that... there are ALOT of
> packages in contrib.
I'm not configure expert, but I think it wouldn't be hard to do
something like --with-contrib='module1 module2 module3'. I believe
there's
Adding to the ambiguity is the dot notation used for
composite columns. Don't forget the other end ignoring
those required parens.
is foo.bar.zap
a database.schema.table
a schema.table.column
a table.column.column
--elein
On Wed, May 11, 2005 at 03:21:42PM -0400, Tom L
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Wed, May 11, 2005 at 05:28:22PM -0400, Tom Lane wrote:
>> No, actually, I was wondering where the potentially N levels of schema
>> names would appear in the output ...
> My immediate thought is that they would be appended together in 'dot
> notation
On Wed, May 11, 2005 at 05:28:22PM -0400, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> > On Wed, May 11, 2005 at 04:49:52PM -0400, Tom Lane wrote:
> >> Besides, I can't wait to hear the moans from the newsysviews crew when
> >> the implications of this sink in ;-) ;-)
>
> > Oh no
Josh Berkus wrote:
Folks,
Hey, I can see a way for /contrib to become a lot better option for
stuff-we're-not-sure-whether-to-include.
What if we could build contrib modules through a build-time switch for
PostgreSQL? Like,
./configure --with-perl --with-dblink --with-newsysviews
This would
On Tue, May 10, 2005 at 09:36:59AM +0200, Nicolai Petri wrote:
> I'm currently building some stored procedures in C that uses some internal
> hash tables - It could be really nice to be able to deallocate those
> correctly when e.g. a memctx is destroyed. Would it be possible to add this
> as a
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Wed, May 11, 2005 at 04:49:52PM -0400, Tom Lane wrote:
>> Besides, I can't wait to hear the moans from the newsysviews crew when
>> the implications of this sink in ;-) ;-)
> Oh no, not recursive function calls! :P
No, actually, I was wondering wher
Folks,
Hey, I can see a way for /contrib to become a lot better option for
stuff-we're-not-sure-whether-to-include.
What if we could build contrib modules through a build-time switch for
PostgreSQL? Like,
./configure --with-perl --with-dblink --with-newsysviews
This would seem a *lot* mor
Andreas,
I think you bring up some good points, but I also think that each package you
propose needs to be dealt with individually.
> - dbsize has been in contrib for a long time, though it appears to me as
> quite a basic functionality to find out about storage needs.
Although not needed so mu
Hello all
I have been studying the rule system in Postgres. I understand that
the original query tree is the input at the rewrite, and then this
query tree is modified by the rewrite in case that there is a rule.
SQL query > Parser > Rewrite > Planner > Executor
On Wed, May 11, 2005 at 04:49:52PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > How is a catalog different from a schema?
>
> In the spec there's a hard-wired difference: catalogs contain schemas,
> schemas don't contain other schemas. The idea at hand here is to make
> our namespaces serv
On Wed, May 11, 2005 at 04:44:21PM +, Andreas Pflug wrote:
> There's still a lengthy discussion going on whether it's a good idea to
> add a forth way to read pgsql's schema (pg_* tables, pg_* views,
> information_schema, did I miss one?), but I'd like to see helper
> functions for issues *n
Bruce Momjian writes:
> How is a catalog different from a schema?
In the spec there's a hard-wired difference: catalogs contain schemas,
schemas don't contain other schemas. The idea at hand here is to make
our namespaces serve both purposes. (I knew there was a good reason
not to use the word
On Wed, May 11, 2005 at 04:44:21PM +, Andreas Pflug wrote:
>
> Yes yes I know, all of these can be done by a local administrator with
> console access and an editor and cmd line tools, but there are indeed
> people that do *not* have console access, or like to use decent tools
Is there
Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> >> There are some nontrivial issues to be thought about here, like under
> >> what conditions "CREATE SCHEMA foo" ought to create a top-level schema
> >> versus creating a schema under some other schema that we are pretending
> >> is the ac
Rod Taylor <[EMAIL PROTECTED]> writes:
>> There are some nontrivial issues to be thought about here, like under
>> what conditions "CREATE SCHEMA foo" ought to create a top-level schema
>> versus creating a schema under some other schema that we are pretending
>> is the active "catalog". But it se
On Wed, 2005-05-11 at 15:41 -0400, Rod Taylor wrote:
> > There are some nontrivial issues to be thought about here, like under
> > what conditions "CREATE SCHEMA foo" ought to create a top-level schema
> > versus creating a schema under some other schema that we are pretending
> > is the active "ca
> There are some nontrivial issues to be thought about here, like under
> what conditions "CREATE SCHEMA foo" ought to create a top-level schema
> versus creating a schema under some other schema that we are pretending
> is the active "catalog". But it seems on first glance like something
> could
On Wed, 2005-05-11 at 13:40 +0100, Mark Cave-Ayland wrote:
> So unless we can guarantee a minimum of 1k data per Xlog record then
> Adler-32 won't be suitable.
Most records are either 8KB or much less than 1KB. Is the benefit gained
from the 8KB records worth the loss on the more frequent smaller
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Aha. ok. should be fairly trivial. I'm thinking of something like
>--load-languages=lang1,lang2,lang3
> (in case we ever want more than one).
Might be a little easier as multiple switches:
--load-language=lang1 --load-language=lang2
Tom Lane wrote:
The point is that I'd rather test createlang than duplicate it.
(In the back of my mind also is that running createlang is a waste of
time for the contrib tests, and so it'd be nice if pg_regress didn't
load any PL unless told to.)
Aha. ok. should be fairly trivial. I'm thinkin
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Andreas Pflug
> Sent: 11 May 2005 17:44
> To: pgsql-hackers@postgresql.org
> Subject: [HACKERS] Server instrumentation for 8.1
>
> There's still a lengthy discussion going on whether it's a
> good
Hi,
On Wed, 11 May 2005, Robert Treat wrote:
has anyone successfully built 7.3.10? I get the following when running
make check on a slackware...
Except geometry, make check runs fine on RHEL ES 4.
--
Devrim GUNDUZ
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.tdm
"Dave Held" <[EMAIL PROTECTED]> writes:
> /*
> * We check the catalog name and then ignore it.
> */
> if (!isValidNamespace(name[0]))
> {
> if (strcmp(name[0], get_database_name(MyDatabaseId)) != 0)
>
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think this would require a small addition to the pg_regress script
>> to make it configurable as to which PL to install, instead of always
>> installing plpgsql, but that seems like a reasonable thing to do.
> I'm not sure why it wo
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 11, 2005 10:55 AM
> To: Dave Held
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Oracle Style packages on postgres
>
>
> "Dave Held" <[EMAIL PROTECTED]> writes:
> > The rule is simple: when
works for me on FC3 (although it fails the geometry test as usual - I
wish we could stop that).
I bet you have a library clash.
cheers
andrew
Robert Treat wrote:
has anyone successfully built 7.3.10? I get the following when running
make check on a slackware...
== removing existing t
To reiterate my point previously: these system views are NOT aimed at the
people on *this* list; they are for the people on the -NOVICE and -GENERAL
lists and IRC and the people who don't yet use PostgreSQL. Please stop
thinking exclusively in terms of whether they would be useful to you,
per
[redirected to -hackers]
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Is it worth rearranging things for plpython so that it follows the same
test layout as the other 2 (i.e. a test subdir with all the test files
and a script called runtest that does the work)? Especially if we b
has anyone successfully built 7.3.10? I get the following when running
make check on a slackware...
== removing existing temp installation==
== creating temporary installation==
== initializing database system
There's still a lengthy discussion going on whether it's a good idea to
add a forth way to read pgsql's schema (pg_* tables, pg_* views,
information_schema, did I miss one?), but I'd like to see helper
functions for issues *not* covered in the core package.
- dbsize has been in contrib for a lo
Thomas, All,
> I guess I'm having difficulty understanding why the system catalogs
> themselves and provision of support for information_schema are not
> sufficient for what exists in core.
Because you can't answer the question: "What tables does user phil have update
permissions on?" or "How ma
I guess I'm having difficulty understanding why the system catalogs
themselves and provision of support for information_schema are not
sufficient for what exists in core.
At one point, there was a stored procedure database for Pl/PgSQL. It
seems like a system view service like that could easily
"Dave Held" <[EMAIL PROTECTED]> writes:
> The rule is simple: when the identifier has more than
> two parts, search for the first part among the schemas first, and then
> the catalogs.
This doesn't actually work, because there is already ambiguity as to
which level the first name is. See for inst
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 10, 2005 11:42 PM
> To: Bruce Momjian
> Cc: Dave Held; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Oracle Style packages on postgres
>
> [...]
> There's been a lot of handwaving about nested sche
Tom Lane wrote:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > On Tue, 10 May 2005, Bruce Momjian wrote:
> >> The current code is nice and localized and doesn't add any burden on our
> >> existing code, which is already complicated enough. I think we either
> >> fix checkfiles.c, or we remov
David Fetter wrote:
> On Tue, May 10, 2005 at 09:49:13PM -0400, Bruce Momjian wrote:
> > David Fetter wrote:
> > > On Tue, May 10, 2005 at 06:55:39PM -0400, Bruce Momjian wrote:
> > > >
> > > > OK, so it seems we need:
> > > >
> > > > o make private objects accessable only to objects in
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: 10 May 2005 23:22
> To: Simon Riggs
> Cc: Bruce Momjian; Mark Cave-Ayland (External);
> pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Cost of XLogInsert CRC calculations
(cut)
> That's awfully vague --- can
On T, 2005-05-10 at 23:09 +0100, Simon Riggs wrote:
> On Tue, 2005-05-10 at 16:31 +0300, Hannu Krosing wrote:
> > > If all partitions in the query had identical indexes on them, then we
> > > have another option. In that case, each index could be thought to form
> > > part of a larger index ordere
On T, 2005-05-10 at 13:17 -0400, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > It's the = operator that Slony adds for xxid comparisons. I didn't even
> > think of changes Slony would have made.
>
> > ssdb=# select * from pg_operator where oid = 716373;
> > oprname | oprnamespace |
66 matches
Mail list logo
