Hi Andrew,
> Right. There's a simple pipeline way to get rid of it:
> psql -t -f query.sql | sed -e '$d' > query.out
Hi Scott,
> Tired of those blank lines in your text files? Grep them away:
> psql -tf query.sql mydatabase | grep -v "^$" > query.out
Thank you Both.
Regards,
Tena Sakai
tsa
Robert Haas wrote:
While investigating some performance problems recently I've had cause
to think about the way PostgreSQL uses hash joins. So here are a few
thoughts. Some of these have been brought up before.
1. When the hash is not expected to spill to disk, it preserves the
pathkeys of the
Bruce Momjian wrote:
Michael Renner wrote:
+ processing. Unfortunately it's currently not possible to expedite
+ the checkpointing done by pg_start_backup.
I have combined the above patch with another change that reports a
checkpoint is taking place:
test=> se
Bruce Momjian writes:
> + ereport(NOTICE,
> + (errmsg("performing checkpoint")));
You've *got* to be kidding.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscrip
Happened to notice this while looking for something else; the \ef
command appears to be missing from \? output. Suggested patch below.
--
Andrew (irc:RhodiumToad)
Index: src/bin/psql/help.c
===
RCS file: /projects/cvsroot/pgsql/src/
Michael Renner wrote:
> Hi,
>
> small patch for the documentation describing the current pg_start_backup
> checkpoint behavior as per
> http://archives.postgresql.org//pgsql-general/2008-09/msg01124.php .
>
> Should we note down a TODO to revisit the current checkpoint handling?
>
> best regar
Hiroshi Inoue wrote:
Heikki Linnakangas wrote:
Tom Lane wrote:
Heikki Linnakangas writes:
Tom Lane wrote:
Maybe use a special string "Translate Me First" that
doesn't actually need to be end-user-visible, just so no one sweats
over
getting it right in context.
Yep, something like that. T
On Thu, Mar 19, 2009 at 4:04 AM, ITAGAKI Takahiro
wrote:
> Robert Haas wrote:
>> >> Works for me. Especially if you want to think more about ANALYZE before
>> >> changing that.
>> >
>> > Well, it's something that would be sane to contemplate adding in 8.4.
>> > It's way too late for any of this o
While investigating some performance problems recently I've had cause
to think about the way PostgreSQL uses hash joins. So here are a few
thoughts. Some of these have been brought up before.
1. When the hash is not expected to spill to disk, it preserves the
pathkeys of the outer side of the jo
Tom Lane wrote:
"Tena Sakai" writes:
I often use a line like:
psql -tf query.sql mydatabase > query.out
-t option gets rid of the heading and count
report at the bottom. There is a blank line
at the bottom, however. Is there any way to
have psql not give me that blank line?
Hi Tom,
I am a bit surprised to hear that that '\n'
is there unconditionally. But I am sure
there are more pressing things for you to
work on. It's something I can live with.
Regards,
Tena Sakai
tsa...@gallo.ucsf.edu
-Original Message-
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
Sent:
"Tena Sakai" writes:
> I often use a line like:
> psql -tf query.sql mydatabase > query.out
> -t option gets rid of the heading and count
> report at the bottom. There is a blank line
> at the bottom, however. Is there any way to
> have psql not give me that blank line?
Doesn't look like it
All,
Please:
A. Stop cc'ing this thread to the WWW list.
B. Please change the topic of this thread to "Duration" or "Time types".
--Josh Berkus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-
Bruce Momjian writes:
> After talking to Tom, I have reverted this patch. It does not contain
> documentation, and are not properly placed, and was submitted in
> February. I was hoping it would be an easy addition but obviously not
> so please resubmit for 8.5. Sorry.
Aside from the lack of d
2009/4/2 Tom Lane :
> Pavel Stehule writes:
>> actually, there isn't any difference between a) and b)
>
>> a) select somevariadicwithany(10);
>> b) select somevariadicwithany(variadic 10);
>
>> in this case the keyword VARIADIC is ignored.
>
> Well, in my mind what the VARIADIC keyword does is it
After talking to Tom, I have reverted this patch. It does not contain
documentation, and are not properly placed, and was submitted in
February. I was hoping it would be an easy addition but obviously not
so please resubmit for 8.5. Sorry.
--
Pavel Stehule writes:
> actually, there isn't any difference between a) and b)
> a) select somevariadicwithany(10);
> b) select somevariadicwithany(variadic 10);
> in this case the keyword VARIADIC is ignored.
Well, in my mind what the VARIADIC keyword does is it prevents the parser
from buildi
On Thu, 2009-04-02 at 15:49 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > Can we add "batches=N" to the EXPLAIN output for Hash and/or Hash Join?
>
> Are you talking about expected batches, or actual batches?
Expected batches for EXPLAIN, both for EXPLAIN ANALYZE.
> If the
> former, would
2009/4/2 Tom Lane :
> Pavel Stehule writes:
>> Our implementation of variadic parameters are not complete. The
>> support of "any" type is incomplete. Modificator VARIADIC for funccall
>> parameters needs transformation from ArrayExpr to standard parameters
>> list.
>
> I don't think I agree with
On Thu, Apr 2, 2009 at 2:58 PM, Heikki Linnakangas
wrote:
> Also, it would be nice to generalize the thing so that it works not only
> with intervals of time, but also floats, integers, numerics etc. The concept
> of an interval is not really tied to timestamps, even though that's probably
> the m
Andrew Gierth writes:
> I think that not only does there need to be another IS_BADRATIO check,
> but also there needs to be some sort of backstop in gistSplit or
> gistUserPicksplit to either recover or (as a last resort) error out
> cleanly rather than crash the entire db in cases that would resu
On Thu, Apr 2, 2009 at 2:50 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Apr 2, 2009 at 2:18 PM, Tom Lane wrote:
>>> If there's a camp that actually *wants* a NULL result for this case,
>>> I missed the reasoning.
>
>> So that we don't break existing apps because of an issue that is
>> t
> "Teodor" == Teodor Sigaev writes:
>> even further. And what confidence do you have that this change
>> eliminates all forms of the problem, anyway?
Teodor> Yes, I think. Because that part of code ( if (IS_BADRATIO)
Teodor> {...} ) is a corner case itself. In example from Andrew, all
Bruce Momjian wrote:
> Tom Lane wrote:
> > Peter Eisentraut writes:
> > > Joshua D. Drake wrote:
> > > Do we want to give a more informative error message, like "not supported
> > > on this platform?"
> >
> > > The trick will be to fit this into the GUC framework.
> >
> > You could do it by enfo
Simon Riggs writes:
> Can we add "batches=N" to the EXPLAIN output for Hash and/or Hash Join?
Are you talking about expected batches, or actual batches? If the
former, would it be sufficient to distinguish "1" from "more than 1"?
If so, maybe changing the node title to "Batched Hash" would do.
On Monday 30 March 2009 15:52:37 Heikki Linnakangas wrote:
> What is happening is that gettext() returns the message in the encoding
> determined by LC_CTYPE, while we expect it to return it in the database
> encoding. Starting with PG 8.3 we enforce that the encoding specified in
> LC_CTYPE matche
On Thu, 2009-04-02 at 21:58 +0300, Heikki Linnakangas wrote:
> > I have not yet implemented temporal join.
>
> That, and temporal union and difference. You have a union operator, but
> that's not enough for a temporal union, as in:
Ok, so you were talking about the relational operators, not inte
On Thu, 2009-03-26 at 17:15 +, Tom Lane wrote:
> Log Message:
> ---
> If we expect a hash join to be performed in multiple batches, suppress
> "physical tlist" optimization on the outer relation (ie, force a projection
> step to occur in its scan). This avoids storing useless column v
On Thursday 02 April 2009 18:29:45 Tom Lane wrote:
> Hmm. Well, if we use pg_tolower then it will only do the right thing
> for ASCII letters, but it seems like non-ASCII in the path leading to
> the postgres binaries would be pretty dang unusual.
Well, Windows localizes the directory names like
Thanks, patch applied.
---
Andrew Gierth wrote:
> > "Bruce" == Bruce Momjian writes:
>
> >> hi all,
> >>
> >> I read the code that it seems easy for the cursor in plpgsql to
> >> return ROW_COUNT after MOVE LAST e
> "Tom" == Tom Lane writes:
> Teodor Sigaev writes:
>> Look at the patch, it fixes the problem by comparing for equality
>> by FPeq() macros which is used everywhere in geometry calculation.
Tom> Ick. FPeq() is a crock; I'd like to see us get rid of it, not
Tom> spread it even further
On Apr 2, 2009, at 11:24 AM, Sam Mason wrote:
Yes, I'd be tempted to pick one and go with it. It's seems a
completely
arbitrary choice one way or the other but the current behaviour is
certainly wrong.
I'd go with returning a zero element array because it would do
the "right thing" more ofte
OK, updated patch attached and applied; thanks.
---
Zdenek Kotala wrote:
> It looks OK now.
>
> Zdenek
>
> Dne 8.03.09 21:58, Robert Lor napsal(a):
>
> >> 2) Maybe
> >>
> >> TRACE_POSTGRESQL_SLRU_READPAGE_PHYSICAL
Pavel Stehule writes:
> Our implementation of variadic parameters are not complete. The
> support of "any" type is incomplete. Modificator VARIADIC for funccall
> parameters needs transformation from ArrayExpr to standard parameters
> list.
I don't think I agree with this change. The point of an
Jeff Davis wrote:
On Thu, 2009-04-02 at 21:19 +0300, Heikki Linnakangas wrote:
The data type itself is quite trivial. It's all the operators that are
more difficult to implement, and also immensely useful. That part is
still incomplete.
Can you please let me know what you find lacking (note:
even further. And what confidence do you have that this change
eliminates all forms of the problem, anyway?
Yes, I think. Because that part of code ( if (IS_BADRATIO) {...} ) is a corner
case itself. In example from Andrew, all boxes are placed to one page because of
floating-point rounding.
Robert Haas writes:
> On Thu, Apr 2, 2009 at 2:18 PM, Tom Lane wrote:
>> If there's a camp that actually *wants* a NULL result for this case,
>> I missed the reasoning.
> So that we don't break existing apps because of an issue that is
> trivial to work around.
We would only be breaking them if
Heikki Linnakangas writes:
> Now, what about the idea of providing a shorthand LOCALE='foo',
> mirroring --locale=foo initdb option? It seems like a good idea, because
> you almost never want to set LC_COLLATE and LC_CTYPE differently. If we
> do that, should LOCALE=foo also imply a per-databas
On Thu, 2009-04-02 at 21:19 +0300, Heikki Linnakangas wrote:
> The data type itself is quite trivial. It's all the operators that are
> more difficult to implement, and also immensely useful. That part is
> still incomplete.
Can you please let me know what you find lacking (note: the SVN repo is
On Thu, Apr 2, 2009 at 2:18 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Apr 2, 2009 at 2:04 PM, Tom Lane wrote:
>>> Right at the moment, if we stick with the historical definition
>>> of the function, *both* camps have to write out their choice of
>>> the above. Seems like this is the
Hi,
I don't know exactly what you want to do but you can begin by looking
here http://neilconway.org/talks/hacking/ (in particular Handout with
excerpts from patch).
can you tell us more ?
Amine
abdelhak benmohamed a écrit :
Hello,
I am learning how to hack PostgreSQL, but it is stil
Teodor Sigaev writes:
> Look at the patch, it fixes the problem by comparing for equality by FPeq()
> macros which is used everywhere in geometry calculation.
Ick. FPeq() is a crock; I'd like to see us get rid of it, not spread it
even further. And what confidence do you have that this change
Bruce Momjian wrote:
Tom Lane wrote:
Magnus Hagander writes:
Tom Lane wrote:
Personally I think the naming decision is close enough to be a coin
toss, and so either choice is fine with me. However, I think it is
Clearly Unacceptable for createdb's switches to be spelled differently
than the
On Thu, Apr 02, 2009 at 02:04:41PM -0400, Tom Lane wrote:
> A correct fix
> outside-the-function would look more like
>
> case when str = '' then '{}'::text[] else string_to_array(str, ',') end
>
> which should correctly yield NULL for NULL input and an empty array
> for empty input. Similarly,
Josh Berkus wrote:
On 4/2/09 8:48 AM, David E. Wheeler wrote:
On Apr 2, 2009, at 7:20 AM, Steven Lembark wrote:
Note that since the Internships are not required to be project code,
we can also take student projects to contribute to our WWW
infrastructure and other areas the project needs some
Robert Haas writes:
> On Thu, Apr 2, 2009 at 2:04 PM, Tom Lane wrote:
>> Right at the moment, if we stick with the historical definition
>> of the function, *both* camps have to write out their choice of
>> the above. Seems like this is the worst of all possible worlds.
>> We should probably pic
The nature of the problem is this: if gist_box_picksplit doesn't find
a good disposition on the first try, then it tries to split the data
again based on the positions of the box centers. But there's a problem
here with floating-point rounding; it's possible for the average of N
Look at the patc
On Thu, Apr 2, 2009 at 2:04 PM, Tom Lane wrote:
> Right at the moment, if we stick with the historical definition
> of the function, *both* camps have to write out their choice of
> the above. Seems like this is the worst of all possible worlds.
> We should probably pick one or the other.
ISTM t
Thank you, fixed
I’ve found a bug about hstore, example below:
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
"David E. Wheeler" writes:
>> Or we could stick to the current behavior and say "use COALESCE() to
>> resolve the ambiguity, if you need to".
> Steve has a point that leaving it as-is leaves it as impossible to
> tell the difference between string_to_array(NULL, ',') and
> string_to_array('',
On 4/2/09 8:48 AM, David E. Wheeler wrote:
On Apr 2, 2009, at 7:20 AM, Steven Lembark wrote:
Note that since the Internships are not required to be project code,
we can also take student projects to contribute to our WWW
infrastructure and other areas the project needs some work.
Would introd
On Thu, Apr 2, 2009 at 10:44 AM, abdelhak benmohamed
wrote:
> I am trying to change syntax of postgresql (for my project). I access to
> gram.y, I add the changes but I still receive message error (syntax error at
> near …).
>
> Is that only change to do or are their other steps to accomplish?
Yo
On Thu, Apr 2, 2009 at 10:59 AM, K. Srinath wrote:
>
> 5. gbl_indx_wip1: patch file w.r.t. anoncvs checkout dated 1 Dec 08.
>
please, update your patch to current HEAD... and add it to
http://wiki.postgresql.org/wiki/CommitFestInProgress
--
Atentamente,
Jaime Casanova
Soporte y capacitación de
On Thu, Apr 2, 2009 at 12:10 PM, David E. Wheeler wrote:
> On Apr 1, 2009, at 12:19 PM, Robert Haas wrote:
>
>>> my @ints = map { $_ || 0 } split ',', $string;
>>>
>>> This ensures that I get the proper number of records in the example of
>>> something like '1,2,,4'.
>>
>> I can't see that there's
"K. Srinath" writes:
> I'm implementing "global index" - an index that indexes all tables in
> an inheritance hierarchy.
This is probably not a good project to tackle as your first Postgres
patch.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
On Thu, Apr 2, 2009 at 12:17 PM, David E. Wheeler wrote:
> On Apr 1, 2009, at 2:22 PM, Tom Lane wrote:
>
>> Another way to state the point is that we can offer people a choice of
>> two limitations: string_to_array doesn't work for zero-length lists,
>> or string_to_array doesn't work for empty st
Martin Pihlak wrote:
> Attached is a patch that modifies psql \dX commands to treat objects
> in information_schema as "system objects". This prevents them from
> showing up in \dX *.* and polluting the user objects list. This is
> especially annoying if user objects are in multiple schemas, and
>
"K. Srinath" writes:
> Why is this so?
Because we don't track inheritance state for attnotnull. There is no
way you can make it work right with marginal hacking on the ATExec
code, because there just isn't enough state.
The correct fix is probably the one alluded to in another thread today:
mak
Hi, the problem goes on. I think the problem is in the planner.c on
grouping_planner function, because when I do a regular sort it gets to it:
/*
* If we were not able to make the plan come out in the right order, add
* an explicit sort step.
*/
if (parse->sortClause)
{
On Apr 1, 2009, at 2:22 PM, Tom Lane wrote:
Another way to state the point is that we can offer people a choice of
two limitations: string_to_array doesn't work for zero-length lists,
or string_to_array doesn't work for empty strings (except most of the
time, it does). The former is sounding le
On Apr 1, 2009, at 12:19 PM, Robert Haas wrote:
my @ints = map { $_ || 0 } split ',', $string;
This ensures that I get the proper number of records in the example
of something like '1,2,,4'.
I can't see that there's any way to do this in SQL regardless of how
we define this operation.
It'
Consider two tables foo(x int not null) and bar (x int).
I fire the sql
SQL1: alter table bar inherit foo;
Above sql causes "ERROR: column "x" in child table must be marked NOT NULL".
This looks logically fine to me.
So, I fire the sql
SQL2: alter table bar alter column x set not null;
Then I
On Apr 2, 2009, at 7:20 AM, Steven Lembark wrote:
Note that since the Internships are not required to be project code,
we can also take student projects to contribute to our WWW
infrastructure and other areas the project needs some work.
Would introducing a Duration (i.e., time-series
a'la Dat
Hitoshi Harada writes:
> The sgml doc mentions about HeapTupleSatisfiesNow() but currently we
> have HeapTupleSatisfiesVisibility() instead.
I think the wording is fine (and more useful) as-is. Remember
HeapTupleSatisfiesVisibility is just a macro, and since we are calling
it with SnapshotNow, t
Magnus Hagander writes:
> And this only shows up when the binary is found in the PATH and not
> through a fully specified directory. This is, AFAICT, the only case
> where they can differ. This is the reason why we haven't had any reports
> of this before - nobody using the installer, or doing eve
Attached patch applied, including documentation updates; I think this
is the best we are going to do to balance usability and consistency. I
have removed this as an open 8.4 item.
With this change \dfS and \df * do the same thing; I assume we don't
want to remove the 'S' modifier and tell peop
Tom Lane wrote:
> Magnus Hagander writes:
>> Tom Lane wrote:
>>> It depends on tolower(), which is going to have LC_CTYPE-dependent
>>> behavior, which is surely wrong?
>
>> Or are you just saying we should be using pg_tolower()? (which I forgot
>> about yet again)
>
> Well, I'd be happier with
Dave Page wrote:
> On Thu, Apr 2, 2009 at 3:46 PM, Tom Lane wrote:
> > Dave Page writes:
> >> In this case, createdb - however, this particular case is of very
> >> minor impact to us. My gripe is more on the general issue of being
> >> potentially forced to add support for a new version and beta
On Thu, Apr 2, 2009 at 3:46 PM, Tom Lane wrote:
> Dave Page writes:
>> In this case, createdb - however, this particular case is of very
>> minor impact to us. My gripe is more on the general issue of being
>> potentially forced to add support for a new version and beta test
>> tools in the same
Tom Lane wrote:
> Dave Page writes:
> > In this case, createdb - however, this particular case is of very
> > minor impact to us. My gripe is more on the general issue of being
> > potentially forced to add support for a new version and beta test
> > tools in the same timeframe that PostgreSQL has
Hello,
I am learning how to hack PostgreSQL, but it is still so difficult in fact, I
am a novice!
I am trying to change syntax of postgresql (for my project). I access to
gram.y, I add the changes but I still receive message error (syntax error at
near …).
Is that only change to do o
Tom Lane wrote:
> "Tao Ma" writes:
>> Is it really important to show the 'bpchar' if there is no any
>> explicit casting for the column default value.
>
> Yeah. We cannot say "char" because per SQL spec, that means
> "char(1)", but there mustn't be a restriction to a single character
> here.
Tom Lane wrote:
> Magnus Hagander writes:
> > Tom Lane wrote:
> >> Personally I think the naming decision is close enough to be a coin
> >> toss, and so either choice is fine with me. However, I think it is
> >> Clearly Unacceptable for createdb's switches to be spelled differently
> >> than the
Dave Page writes:
> In this case, createdb - however, this particular case is of very
> minor impact to us. My gripe is more on the general issue of being
> potentially forced to add support for a new version and beta test
> tools in the same timeframe that PostgreSQL has for beta.
I hear you, bu
Magnus Hagander writes:
> Tom Lane wrote:
>> Personally I think the naming decision is close enough to be a coin
>> toss, and so either choice is fine with me. However, I think it is
>> Clearly Unacceptable for createdb's switches to be spelled differently
>> than the underlying SQL command's opt
Magnus Hagander writes:
> Tom Lane wrote:
>> It depends on tolower(), which is going to have LC_CTYPE-dependent
>> behavior, which is surely wrong?
> Or are you just saying we should be using pg_tolower()? (which I forgot
> about yet again)
Well, I'd be happier with pg_tolower, because I know w
On Thu, Apr 2, 2009 at 3:23 PM, Tom Lane wrote:
> Personally I think the naming decision is close enough to be a coin
> toss, and so either choice is fine with me. However, I think it is
> Clearly Unacceptable for createdb's switches to be spelled differently
> than the underlying SQL command's
Magnus Hagander writes:
> Tom Lane wrote:
>> Comments?
> Certainly seems like a reasonable compromise. From what I understand,
> you'll get this "failed to commit..." message *if* you have changedf
> things in pg_conversion. I think that's acceptable - it's not like
> people modify pg_conversion
Tom Lane wrote:
> Dave Page writes:
>> On Thu, Apr 2, 2009 at 8:47 AM, Heikki Linnakangas
>> wrote:
>>> Now is the time to decide, before the PostgreSQL beta is out. I understand
>>> the pain inflicted on tools, but I don't think that's a good reason to not
>>> change it. People using a beta vers
>> Note that since the Internships are not required to be project code,
>> we can also take student projects to contribute to our WWW
>> infrastructure and other areas the project needs some work.
Would introducing a Duration (i.e., time-series
a'la Date, et al)) data type be considered useful?
Dave Page writes:
> On Thu, Apr 2, 2009 at 8:47 AM, Heikki Linnakangas
> wrote:
>> Now is the time to decide, before the PostgreSQL beta is out. I understand
>> the pain inflicted on tools, but I don't think that's a good reason to not
>> change it. People using a beta version of pgAdmin will sho
"Tao Ma" writes:
> Is it really important to show the
> 'bpchar' if there is no any explicit casting for the column default value.
Yeah. We cannot say "char" because per SQL spec, that means "char(1)",
but there mustn't be a restriction to a single character here.
regression=# select 'abc'::cha
Tom Lane wrote:
> Magnus Hagander writes:
>> Attached patch fixes this in my testcase. Can anybody spot something
>> wrong with it?
>
> It depends on tolower(), which is going to have LC_CTYPE-dependent
> behavior, which is surely wrong?
Not sure, really :) That's the encoding we'd get the paths
Dave Page wrote:
> On Thu, Apr 2, 2009 at 8:47 AM, Heikki Linnakangas
> wrote:
>
> >> As Dave Page pointed
> >> out, other people have already started designing tools based on CVS
> >> HEAD.
> >
> > Now is the time to decide, before the PostgreSQL beta is out. I understand
> > the pain inflicted
Magnus Hagander writes:
> Attached patch fixes this in my testcase. Can anybody spot something
> wrong with it?
It depends on tolower(), which is going to have LC_CTYPE-dependent
behavior, which is surely wrong?
regards, tom lane
--
Sent via pgsql-hackers mailing list (
The sgml doc mentions about HeapTupleSatisfiesNow() but currently we
have HeapTupleSatisfiesVisibility() instead.
Regards,
diff --git a/doc/src/sgml/pgstattuple.sgml b/doc/src/sgml/pgstattuple.sgml
index 821f631..0bba5fe 100644
--- a/doc/src/sgml/pgstattuple.sgml
+++ b/doc/src/sgml/pgstattuple.sg
Robert Haas writes:
> Actually it's more complicated than that. You'd need to remember
> whether or not the NOT NULL was added when the primary key was added,
> or whether it was there before, and only drop it if it wasn't there
> before.
We've discussed before the idea that NOT NULL constraints
Hi,
> >>
> >> Making a column into the primary key forces the column to NOT NULL.
> >> You'll need to DROP NOT NULL separately.
> >>
> >> It's probably possible to beat on the code hard enough to fix this,
> >
> > Yeah it will be a matter of finding the affected column entries and
> invoking
> > t
Bug #4694
(http://archives.postgresql.org/message-id/200903050848.n258mvgm046...@wwwmaster.postgresql.org)
shows a very strange behaviour on windows when you use a different case PATH
>From what I can tell, this is because dir_strcmp() is case sensitive,
but paths on windows are really case-insens
On Thu, Apr 2, 2009 at 8:24 AM, Nikhil Sontakke
wrote:
> Hi,
>>
>> > Considering the following sequence:
>> > create table t(a int primary key);
>> > alter table t drop constraint t_pkey;
>> > insert into t values(null);
>> > ERROR: null value in column "a" violates not-null constrain
Hi,
> > Considering the following sequence:
> >create table t(a int primary key);
> >alter table t drop constraint t_pkey;
> >insert into t values(null);
> >ERROR: null value in column "a" violates not-null constraint
> >
> > My question is, why "null" is not allowed to be inserte
Heikki Linnakangas wrote:
Tom Lane wrote:
Heikki Linnakangas writes:
Tom Lane wrote:
Maybe use a special string "Translate Me First" that
doesn't actually need to be end-user-visible, just so no one sweats
over
getting it right in context.
Yep, something like that. There seems to be a mag
On Thu, Apr 2, 2009 at 3:25 AM, Jacky Leng wrote:
> Considering the following sequence:
> create table t(a int primary key);
> alter table t drop constraint t_pkey;
> insert into t values(null);
> ERROR: null value in column "a" violates not-null constraint
>
> My question is, why "nu
>> I'm speaking primarily of functions as first-class objects, though
>> closures would be nice too. But consider an operation like
>>
>> UPDATE rel SET col1 = MAP ( f OVER col2 )
>>
>> We need to be able to determine whether this is well-typed, just as we
>> do now for any other SQL query. Spec
Tom Lane wrote:
> Magnus Hagander writes:
>> Tom Lane wrote:
>>> What makes more sense to me is to add a table to encnames.c that
>>> provides the gettext name of every encoding that we support.
>
>> Do you mean a separate table there, or should we add a new column to one
>> of the existing table
Tom Lane wrote:
> Magnus Hagander writes:
>> I've seen a couple of reports that the new SSL error messages on windows
>> look strange with paths the wrong way. For example:
>
>> root certificate file "C:\Documents and Settings\\Application
>> Data/postgresql/root.crt" does not exist.
>
>> The is
Tom Lane wrote:
> A problem with such caching is that it'd fail to respond to changes in
> the content of pg_conversion. Now the code is already pretty
> insensitive in that respect, because if you're not doing any fresh "SET
> client_encoding" commands it won't ever notice changes in that catalog
On Thu, Apr 2, 2009 at 8:47 AM, Heikki Linnakangas
wrote:
>> As Dave Page pointed
>> out, other people have already started designing tools based on CVS
>> HEAD.
>
> Now is the time to decide, before the PostgreSQL beta is out. I understand
> the pain inflicted on tools, but I don't think that's
Considering the following sequence:
create table t(a int primary key);
alter table t drop constraint t_pkey;
insert into t values(null);
ERROR: null value in column "a" violates not-null constraint
My question is, why "null" is not allowed to be inserted after primary key
constra
Robert Haas wrote:
On Sat, Mar 28, 2009 at 12:25 PM, Tom Lane wrote:
Robert Haas writes:
On Fri, Mar 27, 2009 at 11:42 AM, Tom Lane wrote:
Both of those things are related to 8.4 feature changes, so we should
either do them now or decide we won't do them.
Well, "Should we have a LOCALE opt
1 - 100 of 101 matches
Mail list logo