ogic elsewhere to disregard oldestOffset when the
accompanying flag is false.
This still leaves open an ugly possibility: can we reach normal
running without a valid oldestOffset? If so, until the next
checkpoint happens, autovacuum has no clue whether it needs to worry.
There's got to be a
ting at a file that has already
> been removed -- again considering the pg_basebackup scenario where the
> multixact files are copied much later than pg_control, so the checkpoint
> to replay is old but the pg_multixact contents have already been
> truncated in the master and
already been removed.
Steve: Can you tell us more about how you shut down the old cluster?
Did you by any chance perform an immediate shutdown? Do you have the
actual log messages that were written when the system was shut down
for the upgrade?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
formed an
immediate shutdown or just pulled the plug, it would have said
"database system was interrupted" or some such.
There may be bugs in redo, also, but they don't explain what happened to Steve.
Steve, is there any chance we can get your pg_controldata output and a
list of all the fi
On Thu, May 28, 2015 at 8:01 AM, Robert Haas wrote:
> On Wed, May 27, 2015 at 6:21 PM, Alvaro Herrera
> wrote:
>> Steve Kehlet wrote:
>>> I have a database that was upgraded from 9.4.1 to 9.4.2 (no pg_upgrade, we
>>> just dropped new binaries in place) but it w
On Thu, May 28, 2015 at 8:03 AM, Robert Haas wrote:
>> Steve, is there any chance we can get your pg_controldata output and a
>> list of all the files in pg_clog?
>
> Err, make that pg_multixact/members, which I assume is at issue here.
> You didn't show us the DET
On Thu, May 28, 2015 at 8:51 AM, Robert Haas wrote:
> [ speculation ]
OK, I finally managed to reproduce this, after some off-list help from
Steve Kehlet (the reporter), Alvaro, and Thomas Munro. Here's how to
do it:
1. Install any pre-9.3 version of the server and generate enough
mu
ct_start(), because TruncateMultiXact()
might get interrupted before it finishes. That seem like an
unnecessary risk.
Thoughts?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
If we remove
> member files, what is it that we try to read and find not to be present?
Do you have a link to the previous discussion?
I mean, the problem we're having right now is that sometimes we have
an offset, but the corresponding member isn't there. So clearly
offsets reference members. Do members also reference offsets? I
didn't think so, but life is full of surprises.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Fri, May 29, 2015 at 10:17 AM, Tom Lane wrote:
> Thomas Munro writes:
>> On Fri, May 29, 2015 at 11:24 AM, Robert Haas wrote:
>>> B. We need to change find_multixact_start() to fail softly.
>
>> Here is an experimental WIP patch that changes StartupMultiXact an
On Fri, May 29, 2015 at 12:43 PM, Robert Haas wrote:
> Working on that now.
OK, here's a patch. Actually two patches, differing only in
whitespace, for 9.3 and for master (ha!). I now think that the root
of the problem here is that DetermineSafeOldestOffset() and
SetMultiXactIdLimi
On Fri, May 29, 2015 at 3:08 PM, Robert Haas wrote:
> It won't fix the fact that pg_upgrade is putting
> a wrong value into everybody's datminmxid field, which should really
> be addressed too, but I've been working on this for about three days
> virtually non-stop and
On Fri, May 29, 2015 at 9:46 PM, Andres Freund wrote:
> On 2015-05-29 15:08:11 -0400, Robert Haas wrote:
>> It seems pretty clear that we can't effectively determine anything
>> about member wraparound until the cluster is consistent.
>
> I wonder if this doesn&#x
hink if we do this, we need to
be very careful about step #2. Right now, we decide what we need to
keep and then remove everything else, but that's kind of wonky because
new stuff may be getting created at the same time, so we keep
adjusting our idea of exactly what needs to be removed. It
On Mon, Jun 1, 2015 at 12:46 AM, Noah Misch wrote:
> Incomplete review, done in a relative rush:
Thanks.
> On Fri, May 29, 2015 at 03:08:11PM -0400, Robert Haas wrote:
>> OK, here's a patch. Actually two patches, differing only in
>> whitespace, for 9.3 and for master (
ly once we're sure that the mxact we plan to call it on actually
exists on disk. That won't be called until we replay the first
checkpoint, but that might still be prior to consistency.
Since I forgot to attach the revised patch with fixes for the points
Noah mentioned to that email, here i
On Tue, Jun 2, 2015 at 1:21 AM, Noah Misch wrote:
> On Mon, Jun 01, 2015 at 02:06:05PM -0400, Robert Haas wrote:
>> On Mon, Jun 1, 2015 at 12:46 AM, Noah Misch wrote:
>> > On Fri, May 29, 2015 at 03:08:11PM -0400, Robert Haas wrote:
>> >> SetMultiXactIdLimit()
yet
> consistent. That really sucks, because we'll possibly end up with
> multixacts that are completely filled by the time we've reached
> consistency.
That would be a departure from the behavior of every existing release
that includes this code based on, to my knowledge, zer
On Tue, Jun 2, 2015 at 11:27 AM, Andres Freund wrote:
> On 2015-06-02 11:16:22 -0400, Robert Haas wrote:
>> I'm having trouble figuring out what to do about this. I mean, the
>> essential principle of this patch is that if we can't count on
>> relminmxid, datmin
se, it
will buy us some time to figure out what else we want to do.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Tue, Jun 2, 2015 at 11:44 AM, Andres Freund wrote:
> On 2015-06-02 11:37:02 -0400, Robert Haas wrote:
>> The exact circumstances under which we're willing to replace a
>> relminmxid with a newly-computed one that differs are not altogether
>> clear to me, but
which should be correct, even though
> possibly overly conservative, in these cases.
Uh oh. That seems like a real bad problem for this approach. What
keeps that from being the opposite of too conservative? There's no
"safe" value in a circular numbering space.
--
Robert
recently:
>
> http://www.postgresql.org/message-id/20150601045534.gb23...@tornado.leadboat.com
>
> He noticed the problem for segment boundaries, when not in recovery.
> In recovery, segment boundaries don't raise an error (the read-zeroes
> case applies), but page boundari
ar numbering space.
>
> I think it *might* (I'm really jetlagged) be fine because that'll only
> happen after a upgrade from < 9.3. And in that case we initialize
> nextOffset to 0. That ought to safe us?
That's pretty much betting the farm on the bugs we know about to
On Wed, Jun 3, 2015 at 8:24 AM, Robert Haas wrote:
> On Tue, Jun 2, 2015 at 5:22 PM, Andres Freund wrote:
>>> > Hm. If GetOldestMultiXactOnDisk() gets the starting point by scanning
>>> > the disk it'll always get one at a segment boundary, right? I'm not s
>> +
>> + /* if nothing has changed, we're done */
>> + if (prevOffsetStopLimitKnown && offsetStopLimit == prevOffsetStopLimit)
>> + return;
>>
>> LWLockAcquire(MultiXactGenLock, LW_EXCLUSIVE);
>> - /* always leave o
On Thu, Jun 4, 2015 at 9:42 AM, Robert Haas wrote:
> Thanks for the review.
Here's a new version. I've fixed the things Alvaro and Noah noted,
and some compiler warnings about set but unused variables.
I also tested it, and it doesn't quite work as hoped. If started
On Thu, Jun 4, 2015 at 1:27 PM, Andres Freund wrote:
> On 2015-06-04 12:57:42 -0400, Robert Haas wrote:
>> + /*
>> + * Do we need an emergency autovacuum? If we're not sure, assume yes.
>> + */
>> + return !oldestOffsetKnown ||
>> +
On Thu, Jun 4, 2015 at 12:57 PM, Robert Haas wrote:
> On Thu, Jun 4, 2015 at 9:42 AM, Robert Haas wrote:
>> Thanks for the review.
>
> Here's a new version. I've fixed the things Alvaro and Noah noted,
> and some compiler warnings about set but unused variables.
On Thu, Jun 4, 2015 at 5:29 PM, Robert Haas wrote:
> - Forces aggressive autovacuuming when the control file's
> oldestMultiXid doesn't point to a valid MultiXact and enables member
> wraparound at the next checkpoint following the correction of that
> problem.
Err, ena
On Fri, Jun 5, 2015 at 2:20 AM, Noah Misch wrote:
> On Thu, Jun 04, 2015 at 05:29:51PM -0400, Robert Haas wrote:
>> Here's a new version with some more fixes and improvements:
>
> I read through this version and found nothing to change. I encourage other
> hackers to
On Fri, Jun 5, 2015 at 12:00 PM, Andres Freund wrote:
> On 2015-06-05 11:43:45 -0400, Tom Lane wrote:
>> Robert Haas writes:
>> > On Fri, Jun 5, 2015 at 2:20 AM, Noah Misch wrote:
>> >> I read through this version and found nothing to change. I encourage
>>
On Fri, Jun 5, 2015 at 2:47 PM, Andres Freund wrote:
> On 2015-06-05 14:33:12 -0400, Tom Lane wrote:
>> Robert Haas writes:
>> > 1. The problem that we might truncate an SLRU members page away when
>> > it's in the buffers, but not drop it from the buffers, leadi
On Fri, Jun 5, 2015 at 2:36 PM, Alvaro Herrera wrote:
> Tom Lane wrote:
>> Robert Haas writes:
>
>> > There are at least two other known issues that seem like they should
>> > be fixed before we release:
>>
>> > 1. The problem that we might truncat
tch I committed today introduces some
regression that is even worse, life will suck.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
s patch is just improving the existing mechanism so
that it's reliable, and you're proposing something notably different
which might be better, but which is really a different proposal
altogether.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
R TABLEs and such. Good to
> know, we'll plan our software updates accordingly.
>
> Is there any risk until these autovacuums finish?
As long as you see only a modest number of files in
pg_multixact/members, you're OK. But in theory, until that emergency
autovacuuming finishes, th
ordering quals in query by their perceived cost
> is the solution. Keep optimizer informed by setting costs appropriately
> and it will do the right thing more often than not. :)
I think that if the costs are actually identical, the system will keep
the quals in the same order they were written
dumpable as well.
>
> That's the reason why the PgQ event tables created by
> pgq.create_queue() are not dumped.
That sucks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgres
of pg_dump to support catalog
> ACLs. I am sure by the way that checking for (owning_tab->dobj.dump &&
> DUMP_COMPONENT_DEFINITION) != 0 is not good because of for example the
> case of a serial column created in an extension where the sequence is
> dropped from the extension afterwards.
Ste
rn false;
+}
Instead of repeating the cleanup code, how about making this break;
then, change the return statement at the bottom of the function to
return (res != -1).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general
, and then you don't need to
reference the number 50 again further down.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
to the people
who do. Whatever is the consensus is OK with me. I just don't want
to get yelled at later for committing something here, so it would be
nice to see a few votes for whatever we're gonna do here.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreS
a variable that you setup and repeat and you show. A
> bit cumbersome and mixes the parts that are title and those that are present
> only because you are watching.
Ah, come on. This doesn't really seem like an issue we should spend
more time quibbling about. I think Tom's versio
be
lightly tested, but it's a pretty confined change, so it's unlikely to
break anything else. ISTM the worst case scenario is that it takes
two minor releases to get it right, and even that seems fairly
unlikely.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Ente
tgresql.org/wiki/PostgreSQL_9.1_Open_Items
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
of those we would have found if the default had been none. I
tend to think DSM is an important facility that we're going to be
wanting to build on in future releases, so I'm keen to have it
available by default so that we can iron out any kinks before we get
too far down that path
oubtful that anyone will get upset if their query plans change
between beta1 and beta2, but the same cannot be said for released
branches.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql
a *non*-MCV can
require a switch to a custom plan, which is something I don't think
I've seen before.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Mon, Nov 17, 2014 at 4:27 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Nov 13, 2014 at 7:34 PM, Tom Lane wrote:
>>> One thing that occurs to me is that if the generic plan estimate comes
>>> out much cheaper than the custom one, maybe we should assume
ranches
> should also be changed.
Sounds reasonable, but I don't see much advantage to changing it in
the back-branches.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To m
On Fri, Mar 31, 2017 at 11:29 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Mar 30, 2017 at 4:45 PM, Tom Lane wrote:
>>> In short, it seems like this statement in the docs is correctly describing
>>> our code's behavior, but said behavior is wrong and sh
I have to dig this up and see if I still have it.
...Robert
-Original Message-
From: Bruce Momjian [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 11, 2008 1:05 PM
To: Robert Haas
Cc: Tom Lane; pgsql-general@postgresql.org
Subject: Re: [GENERAL] contributing patches
Great, would you
On Thu, Sep 24, 2009 at 8:36 PM, Tom Lane wrote:
> BTW, are port numbers still limited to 16 bits in IPv6?
Yes.
...Robert
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Thu, Sep 24, 2009 at 8:59 PM, Tom Lane wrote:
> Sam Mason writes:
>> + if (portnum < 1 || portnum > 65535)
>
> BTW, it strikes me that we could tighten this even more by rejecting
> target ports below 1024. This is guaranteed safe on all Unix systems
> I know of, because privilege
*Don't* VACUUM FULL. Just VACUUM. It's not the same thing.
...Robert
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
linux_sepgsql_context_path(3) is a good watermark of libselinux-2.0.93
> instead.
Looks to me like you need to adjust the wording of the error message.
Maybe "libselinux version 2.0.93 or newer is required", or something like that.
--
Robert Haas
EnterpriseDB: http://www.enterpri
On Wed, Feb 9, 2011 at 4:50 AM, Thom Brown wrote:
> On 9 February 2011 02:11, Robert Haas wrote:
>> On Tue, Feb 8, 2011 at 8:30 PM, Andrew Dunstan wrote:
>>> Quite right, but the commitfest manager isn't meant to be a substitute for
>>> one. Bug fixes aren'
On Fri, Jun 17, 2011 at 2:15 PM, Tom Lane wrote:
> Robert Haas writes:
>> So, I finally got around to look at this, and I think there is a
>> simpler solution. When an overflow occurs while calculating the next
>> value, that just means that the value we're about to
are already tools out there that can monitor this stuff - for
example, check_postgres.pl.
http://bucardo.org/check_postgres/check_postgres.pl.html#sequence
We tend to avoid emitting warnings for this kind of thing because they
can consume vast amounts of disk space, and a lot of times no one
t.
In 9.0+ you can do ALTER TABLE .. ALTER COLUMN .. SET (n_distinct = ...);
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
ase at once would be an optimized situation and perform no worse than
> it does now.
I think you should make more of an effort to understand how the system
works now, and why, before proposing radical redesigns.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
good way to
> do it?
Well, that timestamp will get bumped on TRUNCATE, CLUSTER, VACUUM
FULL, and rewriting versions of ALTER TABLE.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
ocess is that everyone is supposed to pitch
in and help out, not just the committers. That is not happening, and
it's a problem. This process does not work and will not scale if the
committers are responsible for doing all the work on every patch from
beginning to end. That has never worked,
On Tue, Sep 28, 2010 at 9:33 PM, Itagaki Takahiro
wrote:
> On Wed, Sep 29, 2010 at 10:18 AM, Robert Haas wrote:
>> No, the column is very clearly labelled "Reviewers", not "Reviewer".
>> And we have certainly had patches with more than one person's name
I'm trying to write a SQL statement to determine whether a value is an
an array, but I want the comparison to be done using IS NOT DISTINCT
FROM rather than =.
My first thought was that instead of writing:
SELECT value = ANY(array)
...I could simply write:
SELECT value IS NOT DISTINCT FROM ANY(
So, say I have something like this - the actual example is something a
bit more useful:
CREATE TABLE foo (a integer, b integer);
INSERT INTO foo VALUES (1, 1); -- must have some data to generate the failure
CREATE FUNCTION bar (foo) RETURNS SETOF foo AS $$
DECLARE
f foo;
BEGIN
f.a := 1;
xt r;
> end loop;
> return;
> end;
> $$ language plpgsql;
>
> begin;
> declare x cursor for select * from foo;
> select * from bar('x'::refcursor);
> commit;
>
> postgres=# declare x cursor for select * from foo;
> DECLARE CURSOR
> postgres=# select * fr
> You need LATERAL support for this:
> SELECT * FROM foo f LATERAL bar(f);
>
> I'm not sure about the syntax, but LATERAL is a standard JOIN type wherein
> upper "nodes" are visible.
That would be really nice. Then you could presumably also do:
SELECT f.id, f.name, f.apple, f.banana, bar.apple
> * pg_last_recovered_xact_xid()
> Will throw an ERROR if *not* executed in recovery mode.
> returns bigint
>
> * pg_last_completed_xact_xid()
> Will throw an ERROR *if* executed in recovery mode.
> returns bigint
Should these return xid?
...Robert
--
Sent via pgsql-general mailing list (pgsql-
I'm seeing a lot of plans in my database that look like this:
portal=# explain select * from foo i, foo j where i.id = j.id;
QUERY PLAN
-
Hash Join (cost=769.87..2159.36 rows=13283 width=264)
> Could you send the output of these two queries using "explain analyze"
> instead of plain explain?
portal=# explain analyze select * from foo i, foo j where i.id = j.id;
QUERY PLAN
> What's strange about it? A probe into an in-memory hashtable is a lot
> cheaper than a probe into an index, so this type of plan makes plenty
> of sense if the hashtable will fit in RAM and there are going to be a
> lot of probes. (Where "a lot" means "enough to amortize the cost of
> building
>>> Well, that just says your cost parameters need a bit of adjustment
>>> if you'd like the planner to get the crossover point exactly right.
>
>> Any sense of which ones might be worth fiddling with?
>
> random_page_cost, effective_cache_size, maybe the cpu_xxx parameters.
I fiddled with this so
On Sun, Nov 22, 2009 at 6:51 PM, Tom Lane wrote:
> Craig Ringer writes:
>> I do think this comes up often enough that a built-in trigger "update
>> named column with result of expression on insert" trigger might be
>> desirable.
>
> There's something of the sort in contrib already, I believe, tho
On Sun, Nov 22, 2009 at 11:38 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Nov 22, 2009 at 6:51 PM, Tom Lane wrote:
>>> CREATE IF NOT EXISTS has been proposed and rejected before, more than
>>> once. Please see the archives.
>
>> Search for CINE to f
On Tue, Nov 24, 2009 at 12:28 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> So we're conceding that this is a valid need and people will now have
>> a way to meet it. Is the argument against having CINE syntax that it
>> would be more prone to error than the above, or that the code would be
On Tue, Nov 24, 2009 at 2:07 PM, Kevin Grittner
wrote:
> Tom Lane wrote:
>
>> If it did so, that would be outside the apparent meaning of the
>> command, which is to do nothing if an object of that name exists.
>> That's why we've gone with CREATE OR REPLACE instead.
>
> I think that "fail on exi
2009/11/30 rahimeh khodadadi :
>
>
> -- Forwarded message --
> From: rahimeh khodadadi
> Date: 2009/11/29
> Subject: Re: psql+krb5
> To: Denis Feklushkin
Please review the guidelines for reporting a problem, which you can find here:
http://wiki.postgresql.org/wiki/Guide_to_repor
On Tue, Dec 1, 2009 at 11:26 AM, Scott Marlowe wrote:
> Except that he posted a month ago and got no answers...
Gee, I wonder why.
...Robert
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-gene
2009/1/22 Informatica-Cooperativa Cnel. Oviedo :
> Buenos Dias todos,
>
> Soy un usuario de postgres de Paraguay, consulto
> sobre la posibilidad de inclucion en la futura version la siguiente
> sentencia(Uso de alias en la condicion HAVING ):
>
>
> SELECT id, sum(sa
hold user data --- you'd have to mark it as "config" which
> seems a bit unfortunate terminology for that case. Is it important to
> do something about that, and if so what?
Is this anything more than a naming problem?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
T
ht behavior would be if
composite types supported defaults, but they don't, never have, and
maybe never will. I had a previous argument about this with Tom, and
lost, though I am not sure that anyone other than Tom thinks that the
current behavior is for the best. But see commits
tor would, but that concept doesn't really exist
in SQL, which is seemingly deliberately quite murky about when values
spring into existence.
Does the SQL standard say anything on this topic?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via p
On Tue, Mar 31, 2009 at 10:44 AM, Greg Stark wrote:
> On Tue, Mar 31, 2009 at 3:42 PM, Sam Mason wrote:
>>
>> string_to_array('',',')::INT[] => invalid input syntax for integer: ""
>
> Oof. That's a good point.
+1. I find this argument much more compelling than anything else
that's been offer
On Wed, Apr 1, 2009 at 12:52 PM, David E. Wheeler wrote:
> Well, I'd just point out that the return value of string_to_array() is
> text[]. Thus, this is not a problem with string_to_array(), but a casting
> problem from text[] to int[]. Making string_to_array() return a NULL for
> this case to ma
On Wed, Apr 1, 2009 at 1:05 PM, justin wrote:
> I'm still a hold out, We are taking a string putting it into a array based
> on a delimiter. That is very simple and straight forward. Yet many argue
> if we want to cast this into another data type the function should deal with
> in limited cases
On Wed, Apr 1, 2009 at 5:22 PM, Tom Lane wrote:
> Or we could stick to the current behavior and say "use COALESCE() to
> resolve the ambiguity, if you need to".
If there's no consensus on changing the behavior, it's probably better
to be backward compatible than not.
...Robert
--
Sent via pgsq
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
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
>>
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
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
>>>
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 b
So, I have the following problem.
Suppose you have two kinds of animals, sheep and wolves. Since they
have very similar properties, you create a single table to hold both
kinds of animals, and an animal_type table to specify the type of each
animal:
CREATE TABLE animal_type (
id
it would be.
Still, I'd love to see it in the TODO file, too.
...Robert
-Original Message-
From: Joris Dobbelsteen [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 22, 2007 8:03 AM
To: Robert Haas; elein
Cc: pgsql-general@postgresql.org
Subject: RE: [GENERAL] complex referential inte
From: David Fetter [mailto:[EMAIL PROTECTED]
Sent: Monday, February 19, 2007 1:04 PM
To: Robert Haas
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] complex referential integrity constraints
On Fri, Feb 16, 2007 at 09:58:56AM -0500, Robert Haas wrote:
> So, I have the following
ven a few of them. It is exponentially harder to write a
constraint of this type than it is to write a simple foreign key
constraint.
...Robert
-Original Message-
From: Joris Dobbelsteen [mailto:[EMAIL PROTECTED]
Sent: Monday, February 19, 2007 5:59 AM
To: elein; Robert Haas
Cc: pgsql-ge
: Alban Hertroys
Cc: Robert Haas; David Fetter; pgsql-general@postgresql.org
Subject: Re: [GENERAL] complex referential integrity constraints
Alban Hertroys wrote:
> Robert Haas wrote:
> > The idea here is that a wolf can attack a sheep, or a wolf can
attack
> > another wolf, but she
tunately, it's too much work to do it everywhere it would be nice
to have, so I'm just doing it in some really critical cases and hoping
that the others don't break.
Thanks,
...Robert
-Original Message-
From: Alban Hertroys [mailto:[EMAIL PROTECTED]
Sent: Friday, February 23,
--
From: Alban Hertroys [mailto:[EMAIL PROTECTED]
Sent: Monday, February 26, 2007 4:15 AM
To: Robert Haas
Cc: David Fetter; pgsql-general@postgresql.org
Subject: Re: [GENERAL] complex referential integrity constraints
Robert Haas wrote:
> I don't understand what a weighted constraint wo
1 - 100 of 102 matches
Mail list logo
