The following bug has been logged online:
Bug reference: 4412
Logged by: Kevin
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0.15
Operating system: Gentoo Linux
Description:Check constraints cannot be added to the table for
fields that are mixed case
Details
Question:
I have a question about using index in order statement.
Why index ix_2 work by Seq Scan and index ix_3 work by Index Scan.
Example :
ix_2 condition :
When I try
explain
select * from a_test
order by code_ desc
Postgresql response
Sort (cost=11815.08..11852.56 rows=
The following bug has been logged online:
Bug reference: 4245
Logged by: Kevin
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.0
Operating system: Windows
Description:Product Name...
Details:
Last week I placed a new product in the catalog. By mistake I
The following bug has been logged on the website:
Bug reference: 7659
Logged by: Kevin Smith
Email address: ke...@rootsmith.ca
PostgreSQL version: 9.2.1
Operating system: CentOS5
Description:
I have the following in my pg_hba.conf file:
host all +ldap 127.0.0.1/32
on IP
address
> 127.0.0.1.
Exactly what error message do you get in response to what action?
(Copy and paste if possible.)
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
_level = on
autovacuum = on
autovacuum_naptime = 10s
autovacuum_vacuum_threshold = 1
autovacuum_analyze_threshold = 1
datestyle = 'iso, mdy'
lc_messages = 'C'
lc_monetary = 'C'
lc_numeric = 'C'
lc_time = 'C'
escape_string_warning = off
standard_conforming_strings = on
sql_inheritance = off
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
sing CREATE INDEX CONCURRENTLY. Then drop the old index.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
The following bug has been logged online:
Bug reference: 4407
Logged by: Kevin Jenkins
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.3 build1400
Operating system: Windows
Description:Bug in PQexecPrepared when using an integer primary key
that does not
piping from disk into gzip.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
The following bug has been logged online:
Bug reference: 4509
Logged by: Kevin Field
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3.4
Operating system: Windows Server 2003 SP2
Description:array_cat's null behaviour is inconsistent
Details:
Section 9
d time offering useful suggestions without more
detail.
What operating system?
What version of PostgreSQL?
How are you installing it?
What is the exact and full text of the messages, including any user
name?
Does the user name it can't create already exist on your system?
-Kevi
for your intended
use. Start with this page:
http://www.postgresql.org/docs/8.3/interactive/runtime-config-connection.html
Note that the default value for listen_addresses doesn't allow TCP/IP
connections.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.or
EVOKE CREATE ON SCHEMA public FROM public.
GRANT CREATE ON SCHEMA PUBLIC TO table_owner.
A user would need to SET ROLE table_owner to create a table.
RESET ROLE would put them back to normal.
Just a thought
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make
in bug_function
a | b | c | d | e | f | g | h | i | j
---+---+---+---+---+---+---+---+---+---
0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
(1 row)
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
good job of normal
maintenance, you never, ever should be running VACUUM FULL.
None of the above means you haven't found a problem worth looking at
-- I'm not trying to comment on that; but unless you are in the middle
of recovery from abnormal bloat, you may be able to dodge the problem
usually isn't the best option for routine
maintenance. If you notice performance degrading again, please post
details on the performance list.
I hope this helps.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgr
The following bug has been logged online:
Bug reference: 4763
Logged by: Kevin Field
Email address: k...@brantaero.com
PostgreSQL version: 8.4-beta1
Operating system: Windows Server 2003 Standard Edition SP2
Description:postgres service unstable, even during install
> However, after that when I try to run a script to dump another database and
> restore it onto the beta, I get a "file not found" error, which is really
> odd both because it was working fine on the 2009-03-24 build and because the
> permissions have not changed. Aside from that, which is it's ow
On Apr 23, 12:13 pm, dp...@pgadmin.org (Dave Page) wrote:
> On Thu, Apr 23, 2009 at 4:30 PM, Kevin Field
> wrote:
> > Is it possible it's looking for Perl in the wrong place? (Hence the
> > "No such file..." error that somehow makes it back to my Perl script?
On Apr 23, 11:30 am, Kevin Field wrote:
>
> pg_restore: WARNING: database "production" does not exist
> pg_restore: [archiver (db)] Error while PROCESSING TOC:
> pg_restore: [archiver (db)] Error from TOC entry 519; 2612 47275
> PROCEDURAL LANGUAGE plperl mysuperuser
&g
On Apr 23, 2:25 pm, dp...@pgadmin.org (Dave Page) wrote:
> On Thu, Apr 23, 2009 at 6:43 PM, Kevin Field
> wrote:
> > On Apr 23, 12:13 pm, dp...@pgadmin.org (Dave Page) wrote:
> >> On Thu, Apr 23, 2009 at 4:30 PM, Kevin Field
> >> wrote:
> >> > Is it p
On Apr 24, 8:40 am, dp...@pgadmin.org (Dave Page) wrote:
> >
> > So I need to keep my 5.8 around currently for other uses--how can I
> > hint at the correct location for it?
>
> In theory, by setting the path for the server only. In practice I'm
> not sure how you could do that, except by possibly
On Apr 24, 9:32 am, dp...@pgadmin.org (Dave Page) wrote:
>
> I don't know if there is any way we can solve it, except by reverting
> back to 5.8 or advising users to use only one version.
LOL...ah, great. Well, I'd love to move to 5.10 for both.
A note in the docs would be handy either way.
--
On Apr 24, 9:32 am, dp...@pgadmin.org (Dave Page) wrote:
>
> I don't know if there is any way we can solve it, except by reverting
> back to 5.8 or advising users to use only one version.
I just had an idea--at least in the ActiveState distributions (not
sure about Strawberry or Vanilla) they incl
ate_series)
from (select generate_series(1,10) limit 3) x;
sum
-
6
(1 row)
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
I found an additional message in the Application Event Log:
2009-04-17 12:05:00 GMT FATAL: could not create lock file
"postmaster.pid": Permission denied
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsq
BB
> VCCC
> (13 rows)
>
> the sort sequence like ignore the character '.' , '(', ')'. Is it a
> bug ? It is no problem in old version
Probably not a bug; many collating sequences are defined to ignore
such characters. Perhaps you c
On Apr 26, 2:08 pm, dp...@pgadmin.org (Dave Page) wrote:
> On Fri, Apr 24, 2009 at 3:09 PM, Kevin Field
> wrote:
> > On Apr 24, 9:32 am, dp...@pgadmin.org (Dave Page) wrote:
>
> >> I don't know if there is any way we can solve it, except by reverting
> >>
SE Linux)
(1 row)
cc=> show integer_datetimes ;
integer_datetimes
---
on
(1 row)
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
On May 1, 12:41 pm, Kevin Field wrote:
> On Apr 26, 2:08 pm, dp...@pgadmin.org (Dave Page) wrote:
>
> > On Fri, Apr 24, 2009 at 3:09 PM, Kevin Field
> > wrote:
> > > On Apr 24, 9:32 am, dp...@pgadmin.org (Dave Page) wrote:
>
> > >> I don't know
On May 2, 12:09 pm, Kevin Field wrote:
> On May 1, 12:41 pm, Kevin Field wrote:
>
>
>
> > On Apr 26, 2:08 pm, dp...@pgadmin.org (Dave Page) wrote:
>
> > > On Fri, Apr 24, 2009 at 3:09 PM, Kevin Field
> > > wrote:
> > > > On Apr 24, 9:32 am
On May 2, 12:11 pm, Kevin Field wrote:
> On May 2, 12:09 pm, Kevin Field wrote:
>
>
>
> > On May 1, 12:41 pm, Kevin Field wrote:
>
> > > On Apr 26, 2:08 pm, dp...@pgadmin.org (Dave Page) wrote:
>
> > > > On Fri, Apr 24, 2009 at 3:09 PM, Kevin Field
On May 8, 9:11 am, Kevin Field wrote:
> On May 4, 2:10 pm, dp...@pgadmin.org (Dave Page) wrote:
>
> > The installer is still looking for perl58.dll, whilst the server
> > needs perl510.dll. I've committed a fix for that (and the other PLs
> > which were similarly a
On May 22, 9:28 am, Kevin Field wrote:
> On May 8, 9:11 am, Kevin Field wrote:
>
>
>
> > On May 4, 2:10 pm, dp...@pgadmin.org (Dave Page) wrote:
>
> > > The installer is still looking for perl58.dll, whilst the server
> > > needs perl510.dll. I've
ome cases;
this is not the same as specifying SCROLL." Either we make people pay
for this when they haven't specified SCROLL but PostgreSQL has
historically given it to them anyway, or we might break existing
applications.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
se?
It's probably a corollary to the tendency to see our own gaffs when
reading the post coming back from the list much more clearly than they
appeared before clicking "send". :-/
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
/sgml/ltree.sgml:
Example: Top.Countries.Europe.Russia
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ieve values -- it doesn't seem like it would make sense to SET a
value into such a "computed field".)
It's clearly not particular to SQL functions, so it deserves mention
outside of the context you referenced. Chapter 4 does seem like a
good place. Under Column References or F
"Luis angel camacho" wrote:
> the service can't start
How are you starting it?
What error messages, if any, do you see? (Copy/paste if possible;
failing that, please give exact text.)
What is in the logs from around the time of the failed attempt to
start the service?
---
on
(1 row)
ccdev=> create or replace function temp() returns text language
plpgsql
AS $$
begin
return '\';
end; $$;
ERROR: unterminated string
CONTEXT: compile of PL/pgSQL function "temp" near line 2
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql
David Kerr wrote:
> I'm working on my management to allow me to roll my own PG and get a
> 3rd party support.
FWIW, we're a SLES shop, and we've found it best to build our own.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes
uld I resubmit it?
Apparently so. There is often a delay, due to the need for review to
prevent spam from getting through; but sometimes things seem to just
disappear. If it hasn't shown up by now, it's probably not going to
do so.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-b
but plenty large for most
practical uses.)
You can configure PostgreSQL to use integer timestamps in 8.3 if you
build from source, but you will need to convert your database.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://w
isn't that there won't be one; it
just isn't known yet -- which fits the semantics of NULL very well.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
hen you
display it without specifying the time zone in which to view it, so it
shows it in your time zone, which is three hours later by your local
clock.
The withouttimezone column sees the literal in your local time and
calculates what the clock would say in the Pacific time zone at that
moment.
"Kevin Grittner" wrote:
> The withouttimezone column sees the literal in your local time and
s/withouttimezone/withtimezone/
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
8.3 or 8.4, though. Each new major version
contains significant improvements.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
lly* fast if not
much has changed yet.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
"? :" predicate in C. Does anyone else feel that these
aren't implemented quite right in PostgreSQL?
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
"Joseph Shraibman" wrote:
> The pg_relation_size(text) method cannot determine the size of a
> relation that has capital letters.
Did you try putting quotes inside the apostrophes?:
SELECT pg_relation_size('"MixedCaseRelation"');
-Kevin
--
Sent via
Joseph Shraibman wrote:
> Kevin Grittner wrote:
>> Did you try putting quotes inside the apostrophes?:
>>
> No, I didn't. I didn't know I could do that.
That's generally true in recent versions. (Try the -t option on
pg_dump for the first place I ra
character string literals as being of unknown type?
(Other than the obvious backward compatibility issues.)
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Tom Lane wrote:
>>> Joseph Shraibman writes:
>>>> So the type of what is in the ELSE clause determines the type of
>>>> the output?
>>>
>>> If all the other branches are unkno
Jeff Davis wrote:
> On Tue, 2009-09-01 at 13:49 -0500, Kevin Grittner wrote:
>> I figured that; I'm just trying to understand what seems to me like
>> an odd wart on the type system. I figure I must be missing
>> something important, so I'd kinda like to f
Tom Lane wrote:
> "Kevin Grittner" writes:
>> No, that's not it. I'm wondering why it isn't treated as text.
>> Period. Full stop. Nothing to infer.
>
> Because then we would have to provide implicit casts from text to
> everything else,
ping fill in the blanks.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Tom Lane wrote:
> It's interesting that you want to go in 100% the opposite direction
> from Kevin, who seems to want to eliminate type inference
> altogether. Maybe our current compromise isn't too bad, if it makes
> everybody unhappy in opposite directions ;-)
Wel
, COALESCE(NULL, NULL)
currently yields NULL::text. In my view that's wrong. I view it as a
bug, but that seems to be a hard sell here.
Likewise, I think that in the query which started this thread, the
cast to "char" is not sensible. I'm not sure how that could be
resolved, bu
Tom Lane wrote:
> "Kevin Grittner" writes:
>> What I'm most concerned about are the corner cases where strict
>> typing would give one non-error result and the inferred typing
>> results in an error or a different result from the strict typing.
>> I&
understand them, really, but the other way
sounds better)
test=# drop table t;
DROP TABLE
test=# create table t (c varchar(2));
CREATE TABLE
test=# insert into t values ('a');
INSERT 0 1
test=# select case when c = 'a' then 'Hey' else c end from t;
c
-
H
rd
to show where I'm mistaken, I'll look it over. I'll go looking for
something to back my memories on the topic, too, since my memory seems
to be less reliable than it once was.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subs
"Kevin Grittner" wrote:
> Well, unless things have changed in recent versions of the standard
> and I've missed the change, a series of characters enclosed in
> apostrophes is what the standard calls a "character string literal"
> and defines it to be be rel
Tom Lane wrote:
> "Kevin Grittner" writes:
>> And I'm not even sure how I'd explain the rules to someone.
>
> text is preferred to "char" which is preferred to unknown.
>
> This particular example would be less confusing if 'Hey'::&
L being forced to type text in the absence
of any type info in CASE, COALESCE, and NULLIF. If there were a way
to say that these could return unknown type, that would be solved.
That doesn't seem as though it would be likely to be massively
difficult, although I could be wrong about that.
-K
es require a cast, and I'm all for that. Requiring a cast anywhere
else the standard requires it would not offend me; although not
requiring it anywhere it doesn't generate nonstandard results, and
where the semantics are relatively sane, wouldn't offend me, either.
-Kevin
--
Se
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Yep. I don't know if it would be remotely feasible, but the
>> implementation which seems like it would be "standard-safe" but
>> still give reasonable concessions to those wanting to skip the
>>
Sam Mason wrote:
> On Wed, Sep 02, 2009 at 02:59:54PM -0500, Kevin Grittner wrote:
>> Sam Mason wrote:
>> > CREATE VIEW v (c) AS
>> > SELECT NULL;
>> >
>> > PG allows it, but the resulting view seems somewhat unusable.
>>
>>
Tom Lane wrote:
> "Kevin Grittner" writes:
>> go with the suggestion of having a character string literal type,
>> and change the semantics such that if there is a valid
>> interpretation of the statement with the character string literal
>> taken as text,
sting that this is the most urgent issue around.
If anyone can suggest an appropriate wording for a TODO on the topic,
I'll happily shut up and move on ;-)
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
quoted form a match during tab-completion, for
example, is a regular annoyance.)
> So any proposed tweaks in this area would be considered as tradeoffs
> between better spec compliance and other goals.
Fair enough. I consider myself warned. ;-)
-Kevin
--
Sent via pgsql-bugs mailing list
x
(1 row)
Much as the reason for the behavior of "char" may seem clear when
inside the code looking out, it is astonishing for someone writing
application code.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
the given values, regardless of type.
I don't think an error is the right thing, I think returning the
specified value is the right thing. I don't think it's a good thing
that the type system decides that the result type for this case
predicate is "char" and that &
I can't see why invalid literals should
> not be thrown out.
Only, I guess, because of the name. If it weren't called "char" I
guess I wouldn't be concerned about people expecting it to behave
something like char. If "char" behaved more like char, the 'xxx'
literal wouldn't be taken as input to the type in the above CASE
statement.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
against catalog tables or use an internal type in their tables, so I
guess it's not worth going to extremes to make it behave like char.
Given all that, I'll conceed the point, and give a +1 for the error
message.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.or
it an implementation quirk?
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
make it easier to code long string
literals without creating query text which has long line lengths, but
they (understandably) don't require a minimum length for the string
fragments.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
tatements.html
In this case the query will always return one row. The row may have a
NULL if no matching values were found, but the row will be there.
select max(x) from (select generate_series(1,10) as x) y where x > 10;
max
-
(1 row)
Not a bug.
-Kevin
--
Sent via pgsql-bugs m
cc=> select 'a' --comment
'b';
?column?
--
ab
(1 row)
cc=> select 'a' -- comment
-- comment
'b';
?column?
--
ab
(1 row)
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ost a small, self-contained example of code which exhibits
this problem? Also, what are the OS and Java versions on the client
side?
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ession is used
it's not supported syntax, per the above.
> Create index is OK:
as one would expect from the documentation:
( { column | ( expression ) } [ opclass ] [, ...] )
This is not a bug.
Maybe there's a feature request in there, but that would belong on
a different l
Sean Hsien wrote:
> 2009/10/15 Kevin Grittner :
>> what are the OS and Java versions on the client side?
> I'm using CentOS 5.2 64-bits with postgres 8.1.11 + java 6u16, and
> Windows Vista 32-bits with postgres 8.4.1 + java 6u13.
So the Java code is running on the
ince you're running on Linux,
something involving the lockfile utility might suffice.)
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
d that point in my recently proposed
LSB conforming script, but I'm guessing that this fits with other
points in the argument that if what I'm doing in the script is
demonstrably better than current pg_ctl behavior, we should change
pg_ctl to support it rather than scripting around it. (No
"Kevin Grittner" wrote:
> I neglected that point in my recently proposed LSB conforming script
Hmmm... On review, I see that I assumed that the -w switch on pg_ctl
start would cover this. I see that the problem is that this uses psql
to connect to the specified port. Besides
n being
> able to actually issue a SQL command would set that breakage in
> stone.
Sounds good to me, other than it stalls pg_ctl revamp until pg_ping is
done. I don't remember a clear design of what pg_ping should look
like. Does anyone have a clear plan in their head?
-Kevin
--
mber. Well, I guess
if someone subverted the clock it could mislead, but is that really
more likely to cause a false match than a random number?
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
o
> connection string, but I'm not sure that suits pg_ctl's purposes.
I'm a little lost on that. Would it cause any problems for pg_ctl,
or just be more than it would need if it's only implemented there?
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-b
ew copy, which has the same $PGDATA, owner, and port number
as the copy still running in the deleted directory, we have similar
issues to those described in the original post. So, personally, I
consider the data directory a less reliable test than the pid. (We
don't have a lot of OS crash &am
throw
away six of the bits to dress it up as a UUID, though. Do the
libraries for that do enough to introduce entropy to compensate for
the lost bits? Any other benefit I'm missing?
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
nt utility and related postmaster support)
should be a discrete patch. Improvements to pg_ctl and init scripts
would come later, as separate patches?
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
han the delta for *just this change* to pg_ctl. I was
thinking of addressing all pg_ctl issues at once, but perhaps this
one makes sense on its own. If so, your alternative does sound
better.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your s
Robert Haas wrote:
> UUIDs throw away 6 bits?
http://en.wikipedia.org/wiki/Universally_Unique_Identifier#Version_4_.28random.29
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ansaction would have
been rolled back when the server was restarted (or if the connection
was broken). What benefit would you get from the exception you
suggest?
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
bout it.
Since it is a JDBC driver bug, it might be best to post to that list,
with a reference back to this thread. Do you want to put together a
JDBC driver patch, or should I?
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
JDBC driver could
expose serious bugs in application code, and break things which are
currently working, for some values of "working". :-(
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
or it's not your postgresql.conf file.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ting an otherwise unadorned set of characters between two
apostrophes as anything except a character string literal of type
CHARACTER with a length calculated per the above violates the
standard. Rather than pretending otherwise, we should be prepared
to explain the reasons for the deviation, descr
ding user-added ones,
> and most of them share the unadorned string literal as the base
> case for constants. Giving preference to CHARACTER would make
> that machinery a lot less pleasant to use.
Well put.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
ion that you should explicitly give it a type.
Once you shake out any problems from code you are migrating, you'll
find it's not hard to write new code in a way which will work in
either environment.
-Kevin
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make chang
"Kevin Grittner" wrote:
> There is an understandable tendency of those who work deep in the
> guts of the PostgreSQL software, making all this custom type code
> work,
I mangled that sentence worse than usual. The tendency is to see
the PostgreSQL behavior as natura
1 - 100 of 593 matches
Mail list logo
