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
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
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
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
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
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,
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
will make it
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
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
could
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't mean to
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 Eisentraut
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
time)
-
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
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 column IS NULL
The where clause would avoid issues with inherited data being
overwritten when
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:
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 new
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 answer to
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
updated? Are
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
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
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.
When
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
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.
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
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 (Bruce,
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
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
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
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
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 GROUP BY
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,
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 trusted
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, 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 in
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 least
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
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 working
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
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 currently
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, or the
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 CVS
any more
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, 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 contrib
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
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
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
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
47 matches
Mail list logo
