> Why part of the core distribution, and not just left as a loadable module,
> like it is now?
The day I can go 'CREATE FULLTEXT INDEX ...' just like MySQL can I will be a
very happy chappy...
Chris
---(end of broadcast)---
TIP 8: explain analyze
On Fri, 20 Jun 2003, Tom Lane wrote:
> > On Fri, 20 Jun 2003, The Hermit Hacker wrote:
> > Is there a strong reason why tsearch isn't in gborg?
>
> I think text search is a pretty important facility that should
> eventually be part of the core distribution. It's more likely to get
> there from co
> On Fri, 20 Jun 2003, The Hermit Hacker wrote:
> Is there a strong reason why tsearch isn't in gborg?
I think text search is a pretty important facility that should
eventually be part of the core distribution. It's more likely to get
there from contrib than from gborg ...
On Fri, 20 Jun 2003, The Hermit Hacker wrote:
> On Fri, 20 Jun 2003, Oleg Bartunov wrote:
>
> > > Is there a strong reason why tsearch isn't in gborg?
> > >
> >
> > How gborg could help us submitting changes to pgsql CVS ?
>
> It wouldn't ... is there a reason why tsearch needs to be in the pgsql
On Fri, 20 Jun 2003, Oleg Bartunov wrote:
> > Is there a strong reason why tsearch isn't in gborg?
> >
>
> How gborg could help us submitting changes to pgsql CVS ?
It wouldn't ... is there a reason why tsearch needs to be in the pgsql CVS
any more then, say, ODBC drivers, or the tcl interface, o
On Thu, 19 Jun 2003, The Hermit Hacker wrote:
> On Thu, 19 Jun 2003, Oleg Bartunov wrote:
>
> > I'm not sure if contrib/tsearch is a "killer" feature, but we hope to
> > submit completely new version of tsearch V2 before July 1. Actually, we
> > have stable code already used in some projects but c
Attached is a patch that provides *VERY* limited support for multiple slave
servers. I haven't tested it very well, so use at your own risk (and I
recommend against using it in production).
Basically, I have a central database server that has 4 summary tables inside
it replicated to a remote s
On Thu, Jun 19, 2003 at 17:07:43 -0400,
Nailah Ogeer <[EMAIL PROTECTED]> wrote:
Please don't respond to other messages to start a new thread.
> What i am trying to do is to maintain a linked list of all the relations
> in a database. When i create a db then i want it to insert into the linked
>
On Thu, 19 Jun 2003, Oleg Bartunov wrote:
> I'm not sure if contrib/tsearch is a "killer" feature, but we hope to
> submit completely new version of tsearch V2 before July 1. Actually, we
> have stable code already used in some projects but currently lacking
> documentation. Several people are wor
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > Does anyone care about contrib/reindexdb anymore?
>
> I'd think it's still at least as useful as clusterdb. Why, are you
> thinking of doing some work on it?
No, I just noticed that it escaped the C conversion...
Chris
--
> There is no alternative, unless you want the command to be
> non-roll-back-able.
Well, you can do a cluster-type table duplication...
> > Someone can
> > make it more efficient in regards to constraint checks, etc. in the
> > future if they want -- I don't intend to.
>
> It'd be nice if you at
On Thu, 19 Jun 2003, Andrew Dunstan wrote:
>
> Maybe a better strategy would be to get a release out soon but not wait
> 6 months for another release which would contain the Win32 port and the
> PITR stuff (assuming those aren't done in time for this release).
>
> Just a thought.
And definitely i
> See my followup. Which bits of info would you like to see added that
> SHOW doesn't reveal?
Unlike andreas, I'm not interested in the types and ranges of values, what I
need to know is the GUC variables that the user is allowed to set, in
particular what they can ALTER USER / SET ... so that I
On Thu, 19 Jun 2003, Robert Treat wrote:
> Well, I suppose that history has shown that waiting on specific features
> causes trouble with postgresql development, but I don't see why a
> release can't be based around waiting for feature x as long as feature x
> is being actively worked on by truste
> We have a lot of pretty good stuff. You're not happy that the
> performance of IN (subselect) has been fixed?
All our code uses workaround now :)
> That btree index bloat is
> fixed (at least in large part, it remains to be seen whether the field
> performance is all that we need...)?
Yes, t
Tom wrote:
> > Do we have any "killer" features added to 7.4 that we can shout about?
>
> We have a lot of pretty good stuff. You're not happy that the
> performance of IN (subselect) has been fixed? That btree index bloat is
> fixed...
For warehousing & reporting, "Add hash for evaluating GROU
What i am trying to do is to maintain a linked list of all the relations
in a database. When i create a db then i want it to insert into the linked
list the relation ids. As it stands now, i can create a db fine and i see
the relation id's in the linked list. BUT, as soon as i psql into the db
then
On Tue, Jun 17, 2003 at 11:01:27PM -0500, Bruno Wolff III wrote:
>
> My system does have its own sockaddr_storage definition. I think
> it uses __ss_ as the prefix. Also, after looking at the fallback
> definition in pqcomm.h, I don't see where that defines ss_family
> and hence don't see how that
We came across an error while using the hash_search function to find a
database entry in the pg_statdbhash hash table. Just wondering if there
are any recorded errors using this function when doing the initdb. It
seems to work fine while using sql statements but internally something is
going wrong.
Fix the problem and inform the users about code that may break.
Rick
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Hello,
I reported bug #943 (I found in 7.3.2) and you checked in some change against integer
overflow.
Now I upgraded to 7.3.3 and I'm not happy with this.
The exact error as I described is fixed, but I found new errors in conversion UTF-8
<-> EUC_TW and BIG5:
Copy to table (DB has UTF-8 encodin
Hi all,
I am currently implementing an experimental middleware based replicator for
a set
of fully replicated databases.
Do be able to handle all sorts of failures I needed two functions:
- A function to get the current XID
- A function which I can use later to tell if a given XID
commited/abort
On Thu, Jun 19, 2003 at 05:16:10PM +0200, Christian Plattner wrote:
>
> Do be able to handle all sorts of failures I needed two functions:
>
> - A function to get the current XID
> - A function which I can use later to tell if a given XID
> commited/aborted/whatever
I ran into the same need (Bru
here is function to get client ip address (only ipv4),
server address, and fe/be ports , details inside
www.psycho.pl/public/src/pgsql/ivnet.tar.bz2
please test it in yours systems (i tested on Debian 2.4.21 with grsec.)
2. Whatz up with PG_RETURN_UINT16 ??
and with type uintXX ?
And why do you
"Christian Plattner" <[EMAIL PROTECTED]> writes:
> Do be able to handle all sorts of failures I needed two functions:
> - A function to get the current XID
> - A function which I can use later to tell if a given XID
> commited/aborted/whatever
How much later? clog is not kept forever.
On Thu, 19 Jun 2003, Christopher Kings-Lynne wrote:
> Does anyone care about contrib/reindexdb anymore?
I would've found it handy, but didn't know about it and wrote my own in
Perl. Inside a transaction it drops the index then rebuilds it using what
it gets from pg_get_indexdef(), and it looks at
On Thu, 2003-06-19 at 15:00, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > Right now if the column exists in the child table, the add column is
> > rejected. I assume that will remain.
>
> Have you actually tried it?
I used different datatypes which, of course, was the wrong test.
Hi all,
I am currently implementing an experimental middleware based replicator for
a set
of fully replicated databases.
Do be able to handle all sorts of failures I needed two functions:
- A function to get the current XID
- A function which I can use later to tell if a given XID
commited/abort
Rod Taylor <[EMAIL PROTECTED]> writes:
> Right now if the column exists in the child table, the add column is
> rejected. I assume that will remain.
Have you actually tried it?
regression=# create table p1 (f1 int);
CREATE TABLE
regression=# create table c1 (f2 int) inherits(p1);
CREATE TABLE
re
On Thu, 2003-06-19 at 10:42, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > On Thu, 2003-06-19 at 10:05, Alvaro Herrera wrote:
> >> Sorry, I haven't read the spec, but what happens when there is a default
> >> value already and it's not NULL? Are tuples where column =3D default
> >>
Rod Taylor <[EMAIL PROTECTED]> writes:
> On Thu, 2003-06-19 at 10:05, Alvaro Herrera wrote:
>> Sorry, I haven't read the spec, but what happens when there is a default
>> value already and it's not NULL? Are tuples where column =3D default
>> updated? Are tuples where column IS NULL updated?
> W
On Thu, 2003-06-19 at 06:12, Andrew Dunstan wrote:
> Maybe a better strategy would be to get a release out soon but not wait 6
> months for another release which would contain the Win32 port and the PITR
> stuff (assuming those aren't done in time for this release).
Thats what Justin was saying ab
> > Anyway, I suppose you have indirectly confirmed that user triggers, etc.
> > should NOT fire on for the data update. I didn't see anything in the
> > spec that said one way or the other.
>
> The spec doesn't say that they fire, so that means that they don't fire.
Sounds like a definitive ans
On Thu, 2003-06-19 at 10:05, Alvaro Herrera wrote:
> On Thu, Jun 19, 2003 at 09:52:14AM -0400, Rod Taylor wrote:
> > On Thu, 2003-06-19 at 09:40, Tom Lane wrote:
>
> > Do we want them to? If we don't mind them being executed, it is far
> > easier to:
> >
> > - alter table structure
> > - Add all
Maybe a better strategy would be to get a release out soon but not wait 6
months for another release which would contain the Win32 port and the PITR
stuff (assuming those aren't done in time for this release).
Just a thought.
andrew
Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
>>
Rod Taylor <[EMAIL PROTECTED]> writes:
> - alter table structure
> - Add all new constraints (without confirming their correctness at that
> time)
> - update table contents via an SPI call to UPDATE WHERE IS NULL
> The where clause would avoid issues with inherited data being
> overwritten when t
Justin Clift <[EMAIL PROTECTED]> writes:
> Can anyone assist Diogo here?
I've never used cygwin, but given that the errors seem to relate to
semaphore stuff, I wonder whether he's got cygipc installed.
regards, tom lane
---(end of broadcast)---
On Thu, Jun 19, 2003 at 09:52:14AM -0400, Rod Taylor wrote:
> On Thu, 2003-06-19 at 09:40, Tom Lane wrote:
> Do we want them to? If we don't mind them being executed, it is far
> easier to:
>
> - alter table structure
> - Add all new constraints (without confirming their correctness at that
> ti
Rod Taylor writes:
> Anyway, I suppose you have indirectly confirmed that user triggers, etc.
> should NOT fire on for the data update. I didn't see anything in the
> spec that said one way or the other.
The spec doesn't say that they fire, so that means that they don't fire.
--
Peter Eisentra
On Thu, 2003-06-19 at 09:40, Tom Lane wrote:
> Rod Taylor <[EMAIL PROTECTED]> writes:
> > Anyway, I suppose you have indirectly confirmed that user triggers, etc.
> > should NOT fire on for the data update. I didn't see anything in the
> > spec that said one way or the other.
>
> Actually, I didn
Rod Taylor <[EMAIL PROTECTED]> writes:
> Anyway, I suppose you have indirectly confirmed that user triggers, etc.
> should NOT fire on for the data update. I didn't see anything in the
> spec that said one way or the other.
Actually, I didn't mean to take a position one way or the other. You
cou
Robert Treat <[EMAIL PROTECTED]> writes:
> Well, I suppose that history has shown that waiting on specific features
> causes trouble with postgresql development, but I don't see why a
> release can't be based around waiting for feature x as long as feature x
> is being actively worked on by trusted
> > Someone can
> > make it more efficient in regards to constraint checks, etc. in the
> > future if they want -- I don't intend to.
>
> It'd be nice if you at least ensure that all the constraints are checked
> in a single pass over the table (not one per constraint). Right offhand
> I do not s
On Wed, 2003-06-18 at 23:07, Tom Lane wrote:
> "Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> > What about the nested transaction stuff?
>
> With all due respect to Alvaro et al, I can't imagine that that will
> make it into 7.4. (I have no confidence that PITR or Win32 native port
> wil
On Thursday 19 June 2003 03:27, Christopher Kings-Lynne wrote:
> Do we have any "killer" features added to 7.4 that we can shout about?
We should not forget the availability of PostgreSQL companion products, like
pgAdmin3 and PhpPgAdmin3. These two GUIs should be ready for release during
July, a
Hi,
Bingo, count yourself in. :)
Is your preference for translation of website related stuff (i.e.
http://advocacy.postgresql.org), or existing manuals and documentation,
or error messages in the code itself, or ...? (up to you)
Translating some of the web materials into Slovak would open up
Hi everyone,
Can anyone assist Diogo here? He's not some random user, he's our
official Portuguese translator and helps us out a lot. Sounds like he
really needs a hand.
*please*
Regards and best wishes,
Justin Clift
Original Message
Subject: [GENERAL] [CYGWIN] Problems c
Andreas Pflug wrote:
I'd like to have type (bool/numeric/alpha/value list), min, max and
values in pg_settings.
Currently, you can select the name from a combobox, but type any value
you like, waiting for the backend to complain (or accept).
Additionally, it should be marked which vars are lega
Tom Lane wrote:
Yes, you can check if they're binary compatible from the pg_cast table
But nearly all of the interesting cases require you to understand the
type's interpretation of typmod, and you can't learn that from a table.
How many cases are there where blindly looking for a binary-
Tom Lane wrote:
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
SHOW ALL;
Will help, but won't tell the whole story...
See my followup. Which bits of info would you like to see added that
SHOW doesn't reveal?
I'd like to have type (bool/numeric/alpha/value list), min, max and
50 matches
Mail list logo
