mani <[EMAIL PROTECTED]> writes:
> I would like to work on TODO item - "Allow INSERT INTO tab (col1, ..) VALUE=
> S
> (val1, ..), (val2, ..)"
> Any suggestion / comments ?
If you look at the SQL spec, INSERT/VALUES is actually just a special
case --- VALUES is supposed to be a table construct that
I would like to work on TODO item - "Allow INSERT INTO tab (col1, ..) VALUES (val1, ..), (val2, ..)"Any suggestion / comments ?ThanksK. Manikandan
Would the easiest solution be to make a patch to readline for Win32, and
only allow Win32 to link to readline if that patch is in readline, and
spit out a compile error if readline doesn't have that patch.
As far as the license, psql spits out a copyright notice as it starts.
It would be a shame
Added to TODO:
o Allow pg_hba.conf to specify host names along with IP addresses
Host name lookup could occur when the postmaster reads the
pg_hba.conf file, or when the backend starts. Another
solution would be to reverse lookup the connection IP and
In case you missed it:
In 8.2 the settings initdb makes as a default for shared_buffers and
max_fsm_pages will be significantly higher if the machine can stand it.
This should have some good performance impact on the "out of the box"
configuration.
Frankly - supplying more sample configs is
I think we've talked about this a couple times over the years, but I'm not
sure it was resolved or not.
The message post about load testing and SQLite showed PostgreSQL poorly.
Yea, I know, it was the Windows port not being optimized, I can see that,
but it raises something else. A good set of bas
OK, yea, it is inconsistent. I changed it do throw a warning instead.
Only patched to 8.2 because it is a behavior change.
---
Kris Jurka wrote:
>
> Why is latin1 special in its conversion from unconvertible unicode data?
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
> Then the patch safest for just 8.2 then.
My hope is to come up with a better patch which will be acceptable for
both 8.1.x and 8.2.. I'll try and come up with something this week. I
don't think it's a huge issue if it's not in 8.1.3 tho.
Then the patch safest for just 8.2 then.
---
Stephen Frost wrote:
-- Start of PGP signed section.
> * Bruce Momjian (pgman@candle.pha.pa.us) wrote:
> > Is this something we need for 8.1.X?
>
> Personally, I think it's a bug
* Bruce Momjian (pgman@candle.pha.pa.us) wrote:
> Is this something we need for 8.1.X?
Personally, I think it's a bug which should be fixed. I don't think
everyone agrees on that though and there are some parts which could be a
bit controversial. The main issue is that now the entire Kerberos
co
Martijn van Oosterhout wrote:
The docs are your friend, see[1] in particular the input_function and
the receive_function.
[1] http://www.postgresql.org/docs/8.1/interactive/sql-createtype.html
Ok, so there are two 'optional' arguments. Following my suggestion, the
input and receive function
Is this something we need for 8.1.X?
---
Bruce Momjian wrote:
>
> Your patch has been added to the PostgreSQL unapplied patches list at:
>
> http://momjian.postgresql.org/cgi-bin/pgpatches
>
> It will be applied as
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---
St
I have updated the 8.1.X documentation to remove the word "only", which
is confusing.
---
Jim C. Nasby wrote:
> On Thu, Feb 09, 2006 at 10:37:34AM +0100, Csaba Nagy wrote:
> > option can only be set at server start o
On Sun, Feb 12, 2006 at 07:33:30PM +0100, Thomas Hallgren wrote:
> >Very little, as it makes unjustifiable assumptions about all the
> >datatype's support functions being predictably propertied. (There's
> >more than one possible signature, let alone any secondary properties
> >such as volatility
Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> writes:
What do you think of my earlier suggestion. Skip all the 'create function' statements and
just add the "AS 'filename' LANGUAGE C" to the CREATE TYPE.
Very little, as it makes unjustifiable assumptions about all the
datatype's
if we had a pg_vacuum table that had the last timestamp of a vacuum/analyze for
each table and the stats looked like
the default, why not just print a warning message out to the user?
-- Original Message ---
From: Tom Lane <[EMAIL PROTECTED]>
To: Peter Eisentraut <[EMAIL PROTE
On Fri, 2006-02-10 at 17:46 +, Simon Riggs wrote:
> > Lastly, there isn't any obvious reason that I can see for having to
> > change the default assumption about cursors. Most queries don't go
> > through cursors. For those that do, we already document that specifying
> > NO SCROLL can be a p
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Yes, that is what autovacuum does. It detects changes in the database
> and runs analyze if failing to do so would cause PostgreSQL to behave
> badly. I don't know why it's not turned on by default.
Conservatism. It may well be on by default in s
Kenneth Marshall <[EMAIL PROTECTED]> writes:
> If the heads of the disk are in the right location, you could easily do
> more than 1 commit per disk revolution so the values over 2 seconds could
> actually be valid. 9 seconds would be worst case of 1 commit per revolution.
No, because a commit in
> On 2/11/06, Andrej Ricnik-Bay wrote:
>> Has anyone here seen this one before? Do the values
>> appear realistic?
>>
>> http://www.sqlite.org/cvstrac/wiki?p=SpeedComparison
>
> The values appear to originate from an intrsinsically flawed test setup.
>
> Just take the first test. The database has t
> Mark Woodward wrote:
>> My question was based on an observation that ANALYZE and VACUUM are
>> nessisary, both for different reasons. The system or tools must be
>> able to detect substantial changes in the database and at least run
>> analyze if failing to do so would cause PostgreSQL to fail ba
Mark Woodward wrote:
> My question was based on an observation that ANALYZE and VACUUM are
> nessisary, both for different reasons. The system or tools must be
> able to detect substantial changes in the database and at least run
> analyze if failing to do so would cause PostgreSQL to fail badly.
> Mark Woodward wrote:
>> I know this is a kind of stupid question, but postgresql does not
>> behave well when the system changes in a major way without at least
>> an analyze. There must be something that can be done to protect the
>> casual user (or busy sometimes absent minded developer) from t
On Sat, Feb 11, 2006 at 09:21:43PM +0100, Jochem van Dieten wrote:
> On 2/11/06, Andrej Ricnik-Bay wrote:
> > Has anyone here seen this one before? Do the values
> > appear realistic?
> >
> > http://www.sqlite.org/cvstrac/wiki?p=SpeedComparison
>
> The values appear to originate from an intrsinsic
Andrej Ricnik-Bay wrote:
> Has anyone here seen this one before? Do the values
> appear realistic?
>
> http://www.sqlite.org/cvstrac/wiki?p=SpeedComparison
Some of the particularly bad test results for PostgreSQL may be related
to using the default memory configuration and never having run ANALY
26 matches
Mail list logo
