On 7 April 2011 16:56, Tom Lane wrote:
> Brendan Jurd writes:
>> TRAP: FailedAssertion("!((data - start) == data_size)", File:
>> "heaptuple.c", Line: 255)
>
> [ scratches head ... ] That implies that heap_fill_tuple came to a
> different conclusion about a tuple's data size than the immediately
Vladimir Kokovic writes:
> On 4/7/11, Robert Haas wrote:
>> On Wed, Apr 6, 2011 at 4:23 PM, Vladimir Kokovic
>> wrote:
>>> ALTER TABLE "s'd"".s'd"""."s's'd""." ADD COLUMN id bigint DEFAULT
>>> nextval('"s''d".s''d""."s''d".d"s''"');
>>> ERROR: improper relation name (too many dotted names): s'd.
hi,
> I think I see what is going on now. We are sometimes failing to set the
> commitSeqNo correctly on the lock. In particular, if a lock assigned to
> OldCommittedSxact is marked with InvalidSerCommitNo, it will never be
> cleared.
>
> The attached patch corrects this:
> TransferPredicateLock
On Thu, Apr 7, 2011 at 6:49 AM, Andrew Dunstan wrote:
>
> On 04/07/2011 12:29 AM, Tom Lane wrote:
>>
>> Robert Haas writes:
>>>
>>> On Wed, Apr 6, 2011 at 7:54 PM, Stephen Frost wrote:
* Andrew Dunstan (and...@dunslane.net) wrote:
>
> The surprising (to me) consequence was that
On Wed, Apr 6, 2011 at 6:47 PM, Andrew Dunstan wrote:
>
>
> On 04/06/2011 01:34 PM, Dave Page wrote:
>>
>> On Wed, Apr 6, 2011 at 6:27 PM, Peter Eisentraut wrote:
>>>
>>> * I have some doubts about whether the SDK is at all needed or
>>> whether it would suffice by itself. I went wit
2011/4/7 Tatsuo Ishii :
> In my understanding pqc is not designed to be working with pgpool.
> Thus if a user want to use both query cache and query dispatching,
> replication or failover etc. which are provided by pgpool, it seems
> it's not possible. For this purpose maybe user could *cascade* pq
On 04/07/2011 03:48 AM, Alastair Turner wrote:
The problem here is that if Andrew had had the opposite case (a
positive-logic hba entry requiring membership in some group to get into
a database), and that had locked out superusers, he'd be on the warpath
about that too. And with a lot more re
On Thu, Apr 7, 2011 at 2:38 AM, Peter Eisentraut wrote:
>> #-comments seem like a fine idea.
>
> But it would have to be the user that would put the comment in there,
> since we can't really install a default file.
What about preparing something like pgpass.sample and installing it
into $PREFIX/s
* Andrew Dunstan wrote:
On 04/07/2011 03:48 AM, Alastair Turner wrote:
Is the solution possibly to assign positive entries on the basis of
the superuser being a member of all groups but require negative
entries to explicitly specify that they apply to superuser?
I think that's just about g
On 04/07/2011 03:07 PM, Brendan Jurd wrote:
On 7 April 2011 16:56, Tom Lane wrote:
Brendan Jurd writes:
TRAP: FailedAssertion("!((data - start) == data_size)", File:
"heaptuple.c", Line: 255)
[ scratches head ... ] That implies that heap_fill_tuple came to a
different conclusion about a tu
On 04/07/2011 07:33 AM, Christian Ullrich wrote:
* Andrew Dunstan wrote:
On 04/07/2011 03:48 AM, Alastair Turner wrote:
Is the solution possibly to assign positive entries on the basis of
the superuser being a member of all groups but require negative
entries to explicitly specify that the
The attached, applied patch preserves
pg_largeobject_metadata.relfrozenxid in pg_upgrade.
This is needed only in 9.1 because only 9.0 had this table and no one is
upgrading from a 9.0 beta to 9.0 anymore. We basically don't backpatch
9.0 beta fixes at this point.
--
Bruce Momjian htt
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> The problem here is that if Andrew had had the opposite case (a
> positive-logic hba entry requiring membership in some group to get into
> a database), and that had locked out superusers, he'd be on the warpath
> about that too. And with a lot more reason.
Excerpts from Brendan Jurd's message of jue abr 07 03:07:32 -0300 2011:
> Hi folks,
>
> I am running a 9.0.3 Hot Standy + Streaming Replication slave which
> occasionally segfaults (every 1-2 days). I rebuilt Postgres with
> --enable-cassert and --enable-debug, switched on core dumping and
> wait
Andrew Dunstan writes:
> I thought about that. What I'd like to know is how many people actually
> want and use and expect the current behaviour. If it's more than a
> handful (which I seriously doubt) then that's probably the way to go.
> Otherwise it seems more trouble than it's worth.
Well,
YAMAMOTO Takashi wrote:
> LOG: could not truncate directory "pg_serial": apparent
> wraparound
Did you get a warning with this text?:
memory for serializable conflict tracking is nearly exhausted
If not, there's some sort of cleanup bug to fix in the predicate
locking's use of SLRU. It ma
On 04/07/2011 11:01 AM, Tom Lane wrote:
Andrew Dunstan writes:
I thought about that. What I'd like to know is how many people actually
want and use and expect the current behaviour. If it's more than a
handful (which I seriously doubt) then that's probably the way to go.
Otherwise it seems mo
2011/4/5 Masanori Yamazaki :
> Hello
>
> I am sending my proposal about Google Summer Of Code2011.
> It would be nice if you could give me your opinion.
Fantastic! Please submit your proposal through the GSoC website:
http://www.google-melange.com/gsoc/profile/student/google/gsoc2011
-selena
I'm getting some pressure at Red Hat to back-patch this fix:
http://archives.postgresql.org/pgsql-committers/2009-08/msg00068.php
(commit dcb2bda9b7042dbf43f876c94ebf35d951de10e9)
into the RHEL 8.4.x postgresql release. Since I have to do the work
anyway, it seems to me to be sensible to commit th
On Thu, Apr 7, 2011 at 12:10 PM, Tom Lane wrote:
> I'm getting some pressure at Red Hat to back-patch this fix:
> http://archives.postgresql.org/pgsql-committers/2009-08/msg00068.php
> (commit dcb2bda9b7042dbf43f876c94ebf35d951de10e9)
> into the RHEL 8.4.x postgresql release. Since I have to do t
Hi,
On Thursday 07 April 2011 18:10:35 Tom Lane wrote:
> I don't currently have a need to fix this before 8.4, and it looks like
> the existing patch doesn't apply easily to 8.3 anyway. So I'm only
> proposing to do this in 8.4.
> Comments, objections?
I personally look forward to that as it has
Bruce Momjian wrote:
> OK, thanks to RhodiumToad on IRC, I was able to determine the cause of
> the two reported pg_upgrade problems he saw via IRC. It seems toast
> tables have xids and pg_dump is not preserving the toast relfrozenxids
> as it should. Heap tables have preserved relfrozenxids, bu
Original Message
Subject: [TESTERS] [PostgreSQL 9.1 alpha5] OpenBSD and Loongson
Date: Thu, 7 Apr 2011 16:22:46 +0200
From: postgre...@raveland.org
To: pgsql-test...@postgresql.org
Hi,
I need the following patch to make PostgreSQL happy
on Loongson with OpenBSD (http://www.ope
On 4/7/11 9:16 AM, Bruce Momjian wrote:
> OK, thanks to RhodiumToad on IRC, I was able to determine the cause of
>> the two reported pg_upgrade problems he saw via IRC.
BTW, just for the release notes, RhodiumToad == Andrew Gierth.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Josh Berkus writes:
> I need the following patch to make PostgreSQL happy
> on Loongson with OpenBSD (http://www.openbsd.org/loongson.html).
> These restrictions no longer exist on OpenBSD.
> Tested with the latest alpha (9.1 alpha5) and with
> the latest 9 release (9.0.3).
I'm a bit inclined to
Hi!
We need to get a headcount for the PL Summit at PgCon on Saturday, May
21, 2011.
Please sign up using this form: http://chesnok.com/u/1r
A wiki page has been started here:
http://wiki.postgresql.org/wiki/PgCon_2011_PL_Summit
We're also working on updating this page:
http://wiki.postgresql.
On 8 April 2011 00:16, Alvaro Herrera wrote:
> Excerpts from Brendan Jurd's message of jue abr 07 03:07:32 -0300 2011:
>> I am running a 9.0.3 Hot Standy + Streaming Replication slave which
>> occasionally segfaults (every 1-2 days). I rebuilt Postgres with
>> --enable-cassert and --enable-debug,
On Mon, Apr 4, 2011 at 9:25 AM, Merlin Moncure wrote:
> On Sun, Apr 3, 2011 at 6:40 PM, Merlin Moncure wrote:
>> On Sat, Apr 2, 2011 at 8:37 PM, Tom Lane wrote:
>>> Merlin Moncure writes:
On Thu, Mar 31, 2011 at 5:38 PM, Merlin Moncure wrote:
> working on exanding the cache to # xid >
On Thu, Apr 7, 2011 at 1:28 PM, Merlin Moncure wrote:
> int ByteOffset = xid / BITS_PER_BYTE;
whoops, I just notice this was wrong -- the byte offset needs to be
taking bucket into account. I need to clean this up some more
obviously, but the issues at play remain the same
--On 28. März 2011 13:38:23 +0100 Bernd Helmle wrote:
But I think we can just call pg_table_size() regardless in 9.0+; I
believe it'll return the same results as pg_relation_size() on
non-tables. Anyone see a problem with that?
Hmm yeah, seems i was thinking too complicated...here is a cle
Random thought: Wouldn't it be better if there were a setting in psql
that set the linestyle to unicode only if the client encoding was
actually UTF8? This might become more relevant as we set the client
encoding automatically in psql in 9.1. Then a setting of, say,
"unicode-auto" would do the ri
On Thu, 2011-04-07 at 12:16 -0400, Bruce Momjian wrote:
> Bruce Momjian wrote:
> > OK, thanks to RhodiumToad on IRC, I was able to determine the cause of
> > the two reported pg_upgrade problems he saw via IRC. It seems toast
> > tables have xids and pg_dump is not preserving the toast relfrozenxi
On Thu, Apr 07, 2011 at 12:16:55PM -0400, Bruce Momjian wrote:
> Bruce Momjian wrote:
> > OK, thanks to RhodiumToad on IRC, I was able to determine the cause of
> > the two reported pg_upgrade problems he saw via IRC. It seems toast
> > tables have xids and pg_dump is not preserving the toast relf
Jeff Davis wrote:
> > I have added a personal regression test to show which
> > pg_class.relfrozenxid values are not preserved, and with this patch the
> > only ones not preserved are toast tables used by system tables, which
> > are not copied from the old cluster (FirstNormalObjectId = 16384). I
Peter Eisentraut wrote:
> Wouldn't it be better if there were a setting in psql that set the
> linestyle to unicode only if the client encoding was actually
> UTF8?
Is UTF8 the only client encoding in which we currently support the
Unicode character set?
-Kevin
--
Sent via pgsql-hackers ma
Seeing that 9.1-to-9.1 pg_upgrade has apparently been broken for months,
it would probably be good to have some kind of automatic testing for it.
Attached is something I hacked together that at least exposes the
current problems, easily available by typing "make check" and waiting.
It does not yet
Another issue:
...\src\tools\msvc>install "foo bar"
bar""=="" was unexpected at this time.
This makes it seemingly impossible to install into a standard location
such as under "C:\Program Files\".
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
On tor, 2011-04-07 at 09:26 +0100, Dave Page wrote:
> On Wed, Apr 6, 2011 at 6:47 PM, Andrew Dunstan wrote:
> >
> >
> > On 04/06/2011 01:34 PM, Dave Page wrote:
> >>
> >> On Wed, Apr 6, 2011 at 6:27 PM, Peter Eisentraut wrote:
> >>>
> >>> * I have some doubts about whether the SDK is at all
On Thu, Apr 7, 2011 at 22:11, Peter Eisentraut wrote:
> On tor, 2011-04-07 at 09:26 +0100, Dave Page wrote:
>> On Wed, Apr 6, 2011 at 6:47 PM, Andrew Dunstan wrote:
>> >
>> >
>> > On 04/06/2011 01:34 PM, Dave Page wrote:
>> >>
>> >> On Wed, Apr 6, 2011 at 6:27 PM, Peter Eisentraut wrote:
>> >>>
On Thu, Apr 7, 2011 at 3:46 PM, Bruce Momjian wrote:
> Jeff Davis wrote:
>> > I have added a personal regression test to show which
>> > pg_class.relfrozenxid values are not preserved, and with this patch the
>> > only ones not preserved are toast tables used by system tables, which
>> > are not c
On Thu, Apr 7, 2011 at 4:11 PM, Peter Eisentraut wrote:
> On tor, 2011-04-07 at 09:26 +0100, Dave Page wrote:
>> On Wed, Apr 6, 2011 at 6:47 PM, Andrew Dunstan wrote:
>> >
>> >
>> > On 04/06/2011 01:34 PM, Dave Page wrote:
>> >>
>> >> On Wed, Apr 6, 2011 at 6:27 PM, Peter Eisentraut wrote:
>> >>
I wrote:
> YAMAMOTO Takashi wrote:
>
>> LOG: could not truncate directory "pg_serial": apparent
>> wraparound
> there's some sort of cleanup bug to fix in the predicate
> locking's use of SLRU. It may be benign, but we won't really know
> until we find it. I'm investigating.
I'm pretty sur
Robert Haas wrote:
> ISTM we need to force a minor release once we are sure this has
> been corrected. We had also probably put out an announcement
> warning people that have already used pg_upgrade of possible data
> corruption. I'm not sure exactly what the language around that
> should be, bu
As you people think and may be possible that complete implementation of
Eager MVs cannot be completed in summer. So maybe i can pick up the work
left to be done in snapshot MVs. I have cloned the repository of pavel baros
from https://github.com/pbaros/postgres.git and i will be looking to find
wha
On Thu, 2011-04-07 at 15:46 -0400, Bruce Momjian wrote:
> OK, so the only other idea I have is to write some pretty complicated
> query function that does a sequential scan of each toast table and pulls
> the earliest xmin/xmax from the tables and use that to set the
> relfrozenxid (pretty complica
On Wed, Apr 6, 2011 at 3:37 PM, Peter Eisentraut wrote:
> Add traceback information to PL/Python errors
>
> This mimics the traceback information the Python interpreter prints
> with exceptions.
>
> Jan Urbański
On my system this spits out a warning:
plpython.c: In function ‘PLy_traceback’:
plpy
On Thu, Apr 7, 2011 at 4:02 PM, Peter Eisentraut wrote:
> Seeing that 9.1-to-9.1 pg_upgrade has apparently been broken for months,
> it would probably be good to have some kind of automatic testing for it.
> Attached is something I hacked together that at least exposes the
> current problems, easi
On 07/04/11 23:01, Robert Haas wrote:
> On Wed, Apr 6, 2011 at 3:37 PM, Peter Eisentraut wrote:
>> Add traceback information to PL/Python errors
>>
>> This mimics the traceback information the Python interpreter prints
>> with exceptions.
>>
>> Jan Urbański
>
> On my system this spits out a warni
Jeff Davis wrote:
> On Thu, 2011-04-07 at 15:46 -0400, Bruce Momjian wrote:
> > OK, so the only other idea I have is to write some pretty complicated
> > query function that does a sequential scan of each toast table and pulls
> > the earliest xmin/xmax from the tables and use that to set the
> > r
Jeff Davis wrote:
> On Thu, 2011-04-07 at 15:46 -0400, Bruce Momjian wrote:
> > OK, so the only other idea I have is to write some pretty complicated
> > query function that does a sequential scan of each toast table and pulls
> > the earliest xmin/xmax from the tables and use that to set the
> > r
Robert Haas wrote:
> >> Well, that won't work, because VACUUM can't be executed in a transaction
> >> block or function.
> >
> > Good point.
> >
> > The only bright part of this is that missing clog will throw an error so
> > we are not returning incorrect data, and hopefully people will report
> >
On fre, 2011-02-25 at 21:32 +0200, Peter Eisentraut wrote:
> According to the online documentation, the APIs are there:
> http://msdn.microsoft.com/en-ca/library/a7cwbx4t.aspx
>
> Now we'd need someone brave try to make it work. The starting point
> would be to define HAVE_LOCALE_T and then make
Bruce Momjian wrote:
> Robert Haas wrote:
> > >> Well, that won't work, because VACUUM can't be executed in a transaction
> > >> block or function.
> > >
> > > Good point.
> > >
> > > The only bright part of this is that missing clog will throw an error so
> > > we are not returning incorrect data,
On tor, 2011-04-07 at 17:03 -0400, Robert Haas wrote:
> I think it's a worthwhile thing to do, but right now I think it would
> be more helpful if you could help fix the breakage your patch created,
> rather than working on new stuff.
This is part of that.
--
Sent via pgsql-hackers mailing list
On ons, 2011-04-06 at 11:49 -0400, Noah Misch wrote:
> Peter, were you planning to complete this? I can take a swing at it, if it
> would be helpful.
Help is always welcome.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.
On Thu, 2011-04-07 at 17:06 -0400, Bruce Momjian wrote:
> I want to avoid anything that requires a compile because they are hard
> for many sites to install so TransactionIdPrecedes() is out. We will
> need to do this in PL/pgSQL probably.
PL/pgSQL can't see dead rows, so that would not be correc
Jeff Davis wrote:
> On Thu, 2011-04-07 at 17:06 -0400, Bruce Momjian wrote:
> > I want to avoid anything that requires a compile because they are hard
> > for many sites to install so TransactionIdPrecedes() is out. We will
> > need to do this in PL/pgSQL probably.
>
> PL/pgSQL can't see dead row
Bruce Momjian wrote:
> Jeff Davis wrote:
> > On Thu, 2011-04-07 at 17:06 -0400, Bruce Momjian wrote:
> > > I want to avoid anything that requires a compile because they are hard
> > > for many sites to install so TransactionIdPrecedes() is out. We will
> > > need to do this in PL/pgSQL probably.
>
Bruce Momjian wrote:
> all we need to do is set those hint bits before the clog gets
> remove, so maybe just a SELECT * would do the trick!
Does that mean that those experiencing the problem are failing to do
the vacuumdb run which is recommended in the pg_upgrade instructions?
-Kevin
--
S
Kevin Grittner wrote:
> Bruce Momjian wrote:
>
> > all we need to do is set those hint bits before the clog gets
> > remove, so maybe just a SELECT * would do the trick!
>
> Does that mean that those experiencing the problem are failing to do
> the vacuumdb run which is recommended in the pg_u
On Thu, 2011-04-07 at 12:38 -0700, Jeff Davis wrote:
> > Any idea how to correct existing systems? Would VACUUM FREEZE of just
> > the toast tables work?
>
> VACUUM FREEZE will never set the relfrozenxid backward. If it was never
> preserved to begin with, I assume that the existing value could
Jeff Davis wrote:
> On Thu, 2011-04-07 at 12:38 -0700, Jeff Davis wrote:
> > > Any idea how to correct existing systems? Would VACUUM FREEZE of just
> > > the toast tables work?
> >
> > VACUUM FREEZE will never set the relfrozenxid backward. If it was never
> > preserved to begin with, I assume
On Thu, Apr 7, 2011 at 5:20 PM, Peter Eisentraut wrote:
> On tor, 2011-04-07 at 17:03 -0400, Robert Haas wrote:
>> I think it's a worthwhile thing to do, but right now I think it would
>> be more helpful if you could help fix the breakage your patch created,
>> rather than working on new stuff.
>
On Thu, Apr 7, 2011 at 4:49 PM, AAMIR KHAN wrote:
> As you people think and may be possible that complete implementation of
> Eager MVs cannot be completed in summer. So maybe i can pick up the work
> left to be done in snapshot MVs. I have cloned the repository of pavel baros
> from https://githu
On Thu, Apr 7, 2011 at 5:52 PM, Bruce Momjian wrote:
> Jeff Davis wrote:
>> On Thu, 2011-04-07 at 12:38 -0700, Jeff Davis wrote:
>> > > Any idea how to correct existing systems? Would VACUUM FREEZE of just
>> > > the toast tables work?
>> >
>> > VACUUM FREEZE will never set the relfrozenxid backw
On Thu, Apr 7, 2011 at 5:06 PM, Jan Urbański wrote:
> On 07/04/11 23:01, Robert Haas wrote:
>> On Wed, Apr 6, 2011 at 3:37 PM, Peter Eisentraut wrote:
>>> Add traceback information to PL/Python errors
>>>
>>> This mimics the traceback information the Python interpreter prints
>>> with exceptions.
Robert Haas wrote:
> On Thu, Apr 7, 2011 at 5:52 PM, Bruce Momjian wrote:
> > Jeff Davis wrote:
> >> On Thu, 2011-04-07 at 12:38 -0700, Jeff Davis wrote:
> >> > > Any idea how to correct existing systems? ?Would VACUUM FREEZE of just
> >> > > the toast tables work?
> >> >
> >> > VACUUM FREEZE will
> You had better start by getting a clear statement from Pavel as to
> whether he wishes to release the code in that repository under the
> PostgreSQL license. I am not sure that he ever formally submitted it.
I don't think it's reasonable for a student to do that. That really
needs to be up to
On 08/04/11 00:25, Robert Haas wrote:
> On Thu, Apr 7, 2011 at 5:06 PM, Jan Urbański wrote:
>> On 07/04/11 23:01, Robert Haas wrote:
>>> On Wed, Apr 6, 2011 at 3:37 PM, Peter Eisentraut wrote:
Add traceback information to PL/Python errors
This mimics the traceback information the P
It appears that the command processor on Windows 7 has a few quirks that
we need to deal with. If you see odd buildfarm or MSVC build script
failures on W7 that's a likely cause. I'm digging further and should
have some fixes before long.
cheers
andrew
--
Sent via pgsql-hackers mailing lis
On Thu, Apr 07, 2011 at 02:49:29PM -0500, Kevin Grittner wrote:
> Peter Eisentraut wrote:
>
> > Wouldn't it be better if there were a setting in psql that set the
> > linestyle to unicode only if the client encoding was actually
> > UTF8?
>
> Is UTF8 the only client encoding in which we curren
Bruce Momjian wrote:
> > > Yes, it will be reasonable.
> > >
> > >> That means that VACUUM FREEZE of the toast table, if there are no
> > >> concurrent transactions, will freeze all of the tuples; and the
> > >> newFrozenXid should always be seen as newer than the existing (and
> > >> wrong) relfro
On Thu, 2011-04-07 at 20:14 -0400, Bruce Momjian wrote:
> So I think we have four possible approaches to correct databases:
>
> 1) SELECT * to set the hint bits
> 2) VACUUM to set the hint bits
> 3) VACUUM FREEZE to remove the old xids
> 4) some complicated function
>
> I
Jeff Davis wrote:
> On Thu, 2011-04-07 at 20:14 -0400, Bruce Momjian wrote:
> > So I think we have four possible approaches to correct databases:
> >
> > 1) SELECT * to set the hint bits
> > 2) VACUUM to set the hint bits
> > 3) VACUUM FREEZE to remove the old xids
> > 4) some comp
Robert Haas writes:
> On Tue, Apr 5, 2011 at 5:52 PM, Andrew Dunstan wrote:
>> That doesn't mean we should arbitrarily break compatibility with pl/sql, nor
>> that we should feel free to add on warts such as $varname that are
>> completely at odds with the style of the rest of the language. That
Noah Misch wrote:
> On Thu, Apr 07, 2011 at 12:16:55PM -0400, Bruce Momjian wrote:
> > Bruce Momjian wrote:
> > > OK, thanks to RhodiumToad on IRC, I was able to determine the cause of
> > > the two reported pg_upgrade problems he saw via IRC. It seems toast
> > > tables have xids and pg_dump is n
On Apr 7, 2011, at 6:58 PM, Tom Lane wrote:
> Well, if we're going to consider 100% backwards compatibility a "must",
> then we should just stick with what the submitted patch does, ie,
> unqualified names are matched first to query columns, and to parameters
> only if there's no column match. Th
On Thu, Apr 7, 2011 at 9:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Apr 5, 2011 at 5:52 PM, Andrew Dunstan wrote:
>>> That doesn't mean we should arbitrarily break compatibility with pl/sql, nor
>>> that we should feel free to add on warts such as $varname that are
>>> completely at
On Thu, Apr 7, 2011 at 6:31 PM, Josh Berkus wrote:
>> You had better start by getting a clear statement from Pavel as to
>> whether he wishes to release the code in that repository under the
>> PostgreSQL license. I am not sure that he ever formally submitted it.
>
> I don't think it's reasonable
Robert Haas wrote:
I am halfway tempted to say that we need to invent our own procedural
language that is designed not for compatibility with the SQL standard
or Oracle, but for non-crappiness.
I'm way ahead of you on that one. -- Darren Duncan
--
Sent via pgsql-hackers mailing list (pgsql-hac
80 matches
Mail list logo