On Tue, Aug 28, 2012 at 9:47 PM, Tom Lane wrote:
> Robert Haas writes:
> > On Tue, Aug 28, 2012 at 2:55 PM, Tom Lane wrote:
> >> Oh, I'd forgotten that worked that way. Frankly, that makes me quite a
> >> bit more concerned about this proposal than I was before. I do *not*
> >> want to re-int
Bruce Momjian writes:
> On Wed, Aug 29, 2012 at 12:24:26AM -0400, Alvaro Herrera wrote:
>> It's a pretty strange line wrap you got in this version of the patch.
>> Normally we just let the string run past the 78 char limit, without
>> cutting it in any way. And moving the start of the string to t
On August 27, 2012 7:00 PM Amit Kapila wrote:
On August 27, 2012 5:58 PM Heikki Linnakangas wrote:
On 27.08.2012 15:18, Amit kapila wrote:
>>> I have implemented the WAL Reduction Patch for the case of HOT Update as
>> Let's do it for HOT updates only. Simon & Robert made good arguments on
>> wh
On Wed, Aug 29, 2012 at 12:24:26AM -0400, Alvaro Herrera wrote:
> Excerpts from Bruce Momjian's message of mar ago 28 22:21:27 -0400 2012:
> > On Tue, Aug 28, 2012 at 04:25:36PM -0400, Tom Lane wrote:
> > > Bruce Momjian writes:
> > > > Updated patch attached which just reports the file as empty.
I wrote:
> Robert Haas writes:
>> That problem is dead.
> The reason it's dead is that we killed it in 8.3. I don't want it
> coming back to life, but I think that that will be exactly the outcome
> if we let any implicit casts to text get back into the rules for
> operator/function overloading
Excerpts from Bruce Momjian's message of mar ago 28 22:21:27 -0400 2012:
> On Tue, Aug 28, 2012 at 04:25:36PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > Updated patch attached which just reports the file as empty. I assume
> > > we don't want the extra text output for pg_ctl like we d
... btw, the buildfarm says you forgot contrib/ while fixing the
collateral damage from these changes.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-h
2012/8/28 Jim Nasby :
> On 8/28/12 2:51 PM, Pavel Stehule wrote:
>>>
>>> >The thing I don't like about this is it assumes that time is the best
>>> > way to
>>> >refer to when things changed in a system. Not only is that a bad
>>> > assumption,
>>> >it also means that relating things to history bec
Robert Haas writes:
> On Tue, Aug 28, 2012 at 4:47 PM, Tom Lane wrote:
>> The real point here though is that the proposed
>> behavior change will affect all functions, not only the cases where you
>> think there is only one sane behavior. And features such as search paths
>> and default paramete
On 08/28/2012 10:42 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 08/28/2012 09:09 PM, Craig Ringer wrote:
Wouldn't that render the user utterly unable to do anything until you
added a bunch of GRANTs on the system catalogs for that user or a
group they're a member of?
Try it and see. You ca
On Sun, Apr 15, 2012 at 12:29:39PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Thu, Apr 5, 2012 at 2:39 AM, Hitoshi Harada wrote:
> >> On Wed, Apr 4, 2012 at 8:00 AM, Tom Lane wrote:
> >>> Given the lack of complaints since 9.0, maybe we should not fix this
> >>> but just redefine the ne
On Tue, Aug 28, 2012 at 10:51 PM, Tatsuo Ishii wrote:
>> pg_largeobject.pageno is a signed int, so I don't think we can let it go
>> past 2^31-1, so half that.
>>
>> We could buy back the other bit if we redefined the column as oid
>> instead of int4 (to make it unsigned), but I think that would c
On Tue, Aug 28, 2012 at 5:04 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Aug 27, 2012 at 7:43 PM, Tom Lane wrote:
>>> There's also the big-picture question of whether we should just get rid
>>> of fuzzy comparisons in the geometric types instead of trying to hack
>>> indexes to work aro
On Tue, Aug 28, 2012 at 4:47 PM, Tom Lane wrote:
>> Well, I think that when there is only one LPAD function, there is also
>> very little chance that the results will come out differently than the
>> user expected.
>
> [ shrug... ] I'm having a hard time resisting the temptation to point
> out th
> pg_largeobject.pageno is a signed int, so I don't think we can let it go
> past 2^31-1, so half that.
>
> We could buy back the other bit if we redefined the column as oid
> instead of int4 (to make it unsigned), but I think that would create
> fairly considerable risk of confusion between the l
Tatsuo Ishii writes:
> Correct me if I am wrong.
> After expanding large object API to 64-bit, the max size of a large
> object will be 8TB(assuming 8KB default BLKSZ).
> large object max size = pageno(int32) * LOBLKSIZE
> = (2^32-1) * (BLCKSZ / 4)
>
Andrew Dunstan writes:
> On 08/28/2012 09:09 PM, Craig Ringer wrote:
>> Wouldn't that render the user utterly unable to do anything until you
>> added a bunch of GRANTs on the system catalogs for that user or a
>> group they're a member of?
> Try it and see. You can do a lot without having any
Bruce Momjian writes:
> On Tue, Aug 28, 2012 at 04:25:36PM -0400, Tom Lane wrote:
>> The backend side of this looks mostly sane to me (but drop the \n,
>> messages are not supposed to contain those). But the feof test proposed
> Removed. I thought we needed to add \n so that strings >80 would w
On Tue, Aug 28, 2012 at 04:25:36PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Updated patch attached which just reports the file as empty. I assume
> > we don't want the extra text output for pg_ctl like we do for the
> > backend.
>
> The backend side of this looks mostly sane to me (but
I've been looking more closely at add_path() and related functions
while trying to decide exactly how I want to handle cases where all
the available paths for a relation are parameterized (because it's got
unresolved lateral references). It suddenly struck me that I missed
a bet while revising tha
On 08/29/2012 01:32 AM, Robert Haas wrote:
On Tue, Aug 28, 2012 at 1:06 PM, Tom Lane wrote:
Also, right at the moment it's not clear to me whether there are any
other cases besides integer literal vs smallint argument. I think
that's the only particularly surprising case within the numeric
hie
On 08/28/2012 09:09 PM, Craig Ringer wrote:
On 08/29/2012 01:25 AM, David Fetter wrote:
Folks,
There are situations where a "default deny" policy is the best fit.
To that end, I have a modest proposal:
REVOKE PUBLIC FROM role;
Thenceforth, the role in question would only have access to
Correct me if I am wrong.
After expanding large object API to 64-bit, the max size of a large
object will be 8TB(assuming 8KB default BLKSZ).
large object max size = pageno(int32) * LOBLKSIZE
= (2^32-1) * (BLCKSZ / 4)
On 08/29/2012 01:25 AM, David Fetter wrote:
Folks,
There are situations where a "default deny" policy is the best fit.
To that end, I have a modest proposal:
REVOKE PUBLIC FROM role;
Thenceforth, the role in question would only have access to things it
was specifically granted.
Wouldn'
On Tue, Aug 28, 2012 at 5:06 PM, Jim Nasby wrote:
> On 8/28/12 2:51 PM, Pavel Stehule wrote:
>>>
>>> >The thing I don't like about this is it assumes that time is the best
>>> > way to
>>> >refer to when things changed in a system. Not only is that a bad
>>> > assumption,
>>> >it also means that r
Alvaro Herrera writes:
> This patch is mainly doing four things:
> 1. take some typedefs and the HeapTupleData struct definition from
> access/htup.h, and put them in access/tupbasics.h. This new file is
> used as #include in all headers instead of htup.h.
> I'm unsure about the "tupbasics.h" f
On 8/28/12 2:51 PM, Pavel Stehule wrote:
>The thing I don't like about this is it assumes that time is the best way to
>refer to when things changed in a system. Not only is that a bad assumption,
>it also means that relating things to history becomes messy.
On second hand I don't have a problem
Robert Haas writes:
> On Mon, Aug 27, 2012 at 7:43 PM, Tom Lane wrote:
>> There's also the big-picture question of whether we should just get rid
>> of fuzzy comparisons in the geometric types instead of trying to hack
>> indexes to work around them.
> +1 for that approach, but only if I don't h
On 8/27/12 12:40 PM, Robert Haas wrote:
On Sat, Aug 25, 2012 at 1:30 PM, David Johnston wrote:
>My internals knowledge is basically zero but it would seem that If you
>simply wanted the end-of-transaction result you could just record nothing
>during the transaction and then copy whatever values
Robert Haas writes:
> On Tue, Aug 28, 2012 at 2:55 PM, Tom Lane wrote:
>> Oh, I'd forgotten that worked that way. Frankly, that makes me quite a
>> bit more concerned about this proposal than I was before. I do *not*
>> want to re-introduce silent cross-category casts to text, not even if
>> th
On Mon, Aug 27, 2012 at 7:43 PM, Tom Lane wrote:
> There's also the big-picture question of whether we should just get rid
> of fuzzy comparisons in the geometric types instead of trying to hack
> indexes to work around them.
+1 for that approach, but only if I don't have to do the work.
Otherwis
On Tue, Aug 28, 2012 at 2:55 PM, Tom Lane wrote:
> Oh, I'd forgotten that worked that way. Frankly, that makes me quite a
> bit more concerned about this proposal than I was before. I do *not*
> want to re-introduce silent cross-category casts to text, not even if
> there's no other way to match
Bruce Momjian writes:
> Updated patch attached which just reports the file as empty. I assume
> we don't want the extra text output for pg_ctl like we do for the
> backend.
The backend side of this looks mostly sane to me (but drop the \n,
messages are not supposed to contain those). But the fe
Magnus Hagander writes:
> On Tue, Aug 28, 2012 at 6:42 PM, Tom Lane wrote:
>> I don't see anything particularly incorrect about that. The point of
>> the --verbose switch is to track what pg_dump is doing, and if what
>> it's doing involves going through RestoreArchive(), why should we try
>> to
2012/8/28 Jim Nasby :
> On 8/22/12 3:03 AM, Pavel Stehule wrote:
>>>
>>> SELECT coverage_amt
>>> >FROM policy FOR SYSTEM_TIME AS OF '2010-12-01'
>>> >WHERE id = ;
>>> >
>>> >SELECT count(*)
>>> >FROM policy FOR SYSTEM_TIME FROM '2011-11-30' TO '-12-30'
>>> >WHERE vin = 'A';
>>
>> I like
On Tue, Aug 28, 2012 at 9:42 PM, Tom Lane wrote:
> Seems like that's down to the CPU not doing "rep stosq" particularly
> quickly, which might well be chip-specific.
AMD optimization manual[1] states the following:
For repeat counts of less than 4k, expand REP string instructions
into equiva
On 8/22/12 3:03 AM, Pavel Stehule wrote:
SELECT coverage_amt
>FROM policy FOR SYSTEM_TIME AS OF '2010-12-01'
>WHERE id = ;
>
>SELECT count(*)
>FROM policy FOR SYSTEM_TIME FROM '2011-11-30' TO '-12-30'
>WHERE vin = 'A';
I like this design - it is simple without other objects
The thi
On Tue, Aug 28, 2012 at 6:42 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> but in plaintext:
>> $ pg_dump -v postgres -Fp -t t > /dev/null
>> pg_dump: creating TABLE t
>> pg_dump: restoring data for table "t"
>> pg_dump: dumping contents of table t
>> pg_dump: setting owner and privileges for
On Mon, Aug 27, 2012 at 10:17:43PM -0400, Bruce Momjian wrote:
> Seems pg_ctl would also need some cleanup if we change the error
> message and/or timing.
>
> I am thinking we should just change the error message in the postmaster
> and pg_ctl to say the file is empty, and call it done (no hint me
Robert Haas writes:
> On Tue, Aug 28, 2012 at 1:39 PM, Tom Lane wrote:
>> There still won't be a candidate for that one, unless you're proposing
>> to allow explicit-only coercions to be applied implicitly.
> [ not so, see kluge in find_coercion_pathway() ]
Oh, I'd forgotten that worked that wa
Heikki Linnakangas writes:
> On 28.08.2012 20:30, Tom Lane wrote:
>> Fascinating. I'd been of the opinion that modern compilers would inline
>> memset() for themselves and MemSet was probably not better than what the
>> compiler could do these days. What platform are you testing on?
> x64, gcc
On Tue, Aug 28, 2012 at 1:39 PM, Tom Lane wrote:
>> The other case that comes up regularly is someone trying to pass some
>> kind of number to a function such as LPAD(). There is only one LPAD()
>> so no ambiguity exists, but PostgreSQL doesn't even see that there's a
>> candidate.
>
> There stil
On 28.08.2012 20:30, Tom Lane wrote:
Heikki Linnakangas writes:
Drilling into the profile, I came up with three little optimizations:
1. Within spgdoinsert, a significant portion of the CPU time is spent on
line 2033 in spgdoinsert.c:
memset(&out, 0, sizeof(out));
That zeroes out a sma
David,
* David Fetter (da...@fetter.org) wrote:
> There are situations where a "default deny" policy is the best fit.
That's certainly true. It's also what we *have*. The only places where
we aren't "default deny" are places where things have been granted to
"public".
Feel free to revoke "publ
David Fetter writes:
> There are situations where a "default deny" policy is the best fit.
> To that end, I have a modest proposal:
> REVOKE PUBLIC FROM role;
Neither possible nor sensible. PUBLIC means everybody, and is
implemented in a way that doesn't allow any other meaning.
We pretty
On 8/27/12 5:19 PM, Greg Sabino Mullane wrote:
Tom Lane replied:
>>>Come on, really? Note that the above example works without casts if
>>>you use int*or* bigint*or* numeric, but not smallint. That could be
>>>fixed by causing sufficiently-small integers to lex as smallints,
>>Is there any
Robert Haas writes:
> On Tue, Aug 28, 2012 at 1:06 PM, Tom Lane wrote:
>> Also, right at the moment it's not clear to me whether there are any
>> other cases besides integer literal vs smallint argument. I think
>> that's the only particularly surprising case within the numeric
>> hierarchy ---
On Tue, Aug 28, 2012 at 12:47 PM, Andres Freund wrote:
> On Tuesday, August 28, 2012 06:39:50 PM Tom Lane wrote:
>> Or maybe we should disable event triggers altogether in standalone mode?
>> I can think of plenty of ways that a broken event trigger could cause
>> enough havoc that you'd wish ther
On Tue, Aug 28, 2012 at 1:06 PM, Tom Lane wrote:
> Also, right at the moment it's not clear to me whether there are any
> other cases besides integer literal vs smallint argument. I think
> that's the only particularly surprising case within the numeric
> hierarchy --- and for non-numeric types,
Heikki Linnakangas writes:
> Drilling into the profile, I came up with three little optimizations:
> 1. Within spgdoinsert, a significant portion of the CPU time is spent on
> line 2033 in spgdoinsert.c:
> memset(&out, 0, sizeof(out));
> That zeroes out a small struct allocated in the stack. R
Folks,
There are situations where a "default deny" policy is the best fit.
To that end, I have a modest proposal:
REVOKE PUBLIC FROM role;
Thenceforth, the role in question would only have access to things it
was specifically granted.
What say?
Cheers,
David.
--
David Fetter http://fett
Greg Stark writes:
> Perhaps just a warning on CREATE FUNCTION when one of the arguments
> doesn't have an implicit cast from the canonical data type of that
> hierarchy saying perhaps you should consider using that data type and
> let Postgres convert instead of the more specific data type?
This
On Tue, Aug 28, 2012 at 10:43:07AM -0400, Robert Haas wrote:
> On Mon, Aug 27, 2012 at 11:13 PM, Greg Smith wrote:
> > After staring at all the examples I generated again, I think Bruce is right
> > that the newer format he's suggesting is better.
>
> OK by me, then. If you're happy, I'm happy.
On Fri, Mar 30, 2012 at 08:15:22PM +0200, Erik Rijkers wrote:
> (in hopes that the current changes to tab-completion will help to get this
> fixed)
>
> tab-completion goes wrong on SET setting=...
>
> example:
>
> If you want to input "set search_path=myschema;" without spaces around '=',
> and
On Mon, Aug 27, 2012 at 10:03 PM, Robert Haas wrote:
> We really ought to put some effort into solving this problem. I've
> seen a few Oracle-migration talks at conferences, and *every one* of
> them has mentioned the smallint problem. It hits our customers, too.
I'm kind of puzzled how Oracle-
On Tuesday, August 28, 2012 06:39:50 PM Tom Lane wrote:
> Or maybe we should disable event triggers altogether in standalone mode?
> I can think of plenty of ways that a broken event trigger could cause
> enough havoc that you'd wish there was a way to suppress it, at least
> for long enough to dro
Magnus Hagander writes:
> but in plaintext:
> $ pg_dump -v postgres -Fp -t t > /dev/null
> pg_dump: creating TABLE t
> pg_dump: restoring data for table "t"
> pg_dump: dumping contents of table t
> pg_dump: setting owner and privileges for TABLE t
> pg_dump: setting owner and privileges for TABLE
I find $SUBJECT fairly scary, because systable_beginscan_ordered() is
dependent on having a working, non-corrupt index. If you are trying
to run the backend with ignore_system_indexes so that you can rebuild
corrupt indexes, uses of systable_beginscan_ordered() represent places
where you can't tur
On Tue, Aug 28, 2012 at 06:08:59PM +0200, Kohei KaiGai wrote:
> 2012/8/28 David Fetter :
> > On Tue, Aug 28, 2012 at 05:18:34PM +0200, Kohei KaiGai wrote:
> >> 2012/8/28 David Fetter :
> >> > On Tue, Aug 28, 2012 at 10:58:25AM -0400, Tom Lane wrote:
> >> >> Kohei KaiGai writes:
> >> >> > It seems
2012/8/28 David E. Wheeler :
> On Aug 28, 2012, at 8:19 AM, Fabrízio de Royes Mello wrote:
>
>>> - Should this patch implements others INEs like ADD COLUMN IF NOT EXISTS?
>>
>> If this feature is important I believe we must implement it.
>>
>> Exists several "CREATE" statements without "IF NOT EXIS
On Mon, Aug 27, 2012 at 11:56:32PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Fri, Mar 9, 2012 at 04:36:08PM -0800, David E. Wheeler wrote:
> >> A bigint key is displayed with its
> >> high-order half in the classid column, its low-order
> >> half
> >> in the objid colu
On Aug 27, 2012, at 8:56 PM, Tom Lane wrote:
> This formula is not actually correct, as you'd soon find out if you
> experimented with values with the high-order bit of the low-order word
> set. (Hint: sign extension.)
>
> The correct formula is both simpler and far more efficient:
>
> (classid
2012/8/28 David Fetter :
> On Tue, Aug 28, 2012 at 05:18:34PM +0200, Kohei KaiGai wrote:
>> 2012/8/28 David Fetter :
>> > On Tue, Aug 28, 2012 at 10:58:25AM -0400, Tom Lane wrote:
>> >> Kohei KaiGai writes:
>> >> > It seems to me TargetEntry of the parse tree can inform us
>> >> > which column sho
On Aug 28, 2012, at 8:19 AM, Fabrízio de Royes Mello wrote:
>> - Should this patch implements others INEs like ADD COLUMN IF NOT EXISTS?
>
> If this feature is important I believe we must implement it.
>
> Exists several "CREATE" statements without "IF NOT EXISTS" option too, so we
> can discus
On Tue, Aug 28, 2012 at 09:40:33AM +0530, Amit Kapila wrote:
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Bruce Momjian
>
> > Added to TODO:
>
> > Allow reporting of stalls due to wal_buffer wrap-around
>
> >
> http://archives.po
2012/8/28 Tom Lane :
> Kohei KaiGai writes:
>>> Would it be too invasive to introduce a new pointer in TupleTableSlot
>>> that is NULL for anything but virtual tuples from foreign tables?
>
>> I'm not certain whether the duration of TupleTableSlot is enough to
>> carry a private datum between scan
On Tue, Aug 28, 2012 at 05:18:34PM +0200, Kohei KaiGai wrote:
> 2012/8/28 David Fetter :
> > On Tue, Aug 28, 2012 at 10:58:25AM -0400, Tom Lane wrote:
> >> Kohei KaiGai writes:
> >> > It seems to me TargetEntry of the parse tree can inform us
> >> > which column should be modified on UPDATE or INS
2012/8/27 Dickson S. Guedes
>
> [...]
>
> Two questions:
>
> - Should this patch implements others INEs like ADD COLUMN IF NOT EXISTS?
>
If this feature is important I believe we must implement it.
Exists several "CREATE" statements without "IF NOT EXISTS" option too, so
we can discuss more abo
2012/8/28 David Fetter :
> On Tue, Aug 28, 2012 at 10:58:25AM -0400, Tom Lane wrote:
>> Kohei KaiGai writes:
>> > It seems to me TargetEntry of the parse tree can inform us which column
>> > should be modified on UPDATE or INSERT. If it has just a Var element
>> > that reference original table as-
Excerpts from Magnus Hagander's message of mar ago 28 08:08:24 -0400 2012:
> In particular, the "restoring data" is obviously completely wrong. But
> AFAICT, the "creating table" and "setting owner" etc are also wrong...
>
> This is because pg_dump calls RestoreArchive(fout).
>
> Do we need to p
On Tue, Aug 28, 2012 at 10:58:25AM -0400, Tom Lane wrote:
> Kohei KaiGai writes:
> > It seems to me TargetEntry of the parse tree can inform us which column
> > should be modified on UPDATE or INSERT. If it has just a Var element
> > that reference original table as-is, it means here is no change.
Kohei KaiGai writes:
> It seems to me TargetEntry of the parse tree can inform us which column
> should be modified on UPDATE or INSERT. If it has just a Var element
> that reference original table as-is, it means here is no change.
Only if you're not going to support BEFORE triggers modifying th
Kohei KaiGai writes:
>> Would it be too invasive to introduce a new pointer in TupleTableSlot
>> that is NULL for anything but virtual tuples from foreign tables?
> I'm not certain whether the duration of TupleTableSlot is enough to
> carry a private datum between scan and modify stage.
It's not
On Mon, Aug 27, 2012 at 11:13 PM, Greg Smith wrote:
> After staring at all the examples I generated again, I think Bruce is right
> that the newer format he's suggesting is better.
OK by me, then. If you're happy, I'm happy.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterpri
On Mon, Aug 27, 2012 at 7:13 PM, Tom Lane wrote:
> Robert Haas writes:
>> I agree that redefining the lexer behavior is a can of worms. What I
>> don't understand is why f(2+2) can't call f(smallint) when that's the
>> only extant f. It seems to me that we could do that without breaking
>> anyt
$ pg_dump -v postgres -Fc -t t > /dev/null
...
pg_dump: dumping contents of table t
...
but in plaintext:
$ pg_dump -v postgres -Fp -t t > /dev/null
pg_dump: creating TABLE t
pg_dump: restoring data for table "t"
pg_dump: dumping contents of table t
pg_dump: setting owner and privileges for TABLE
I did some performance testing of building an SP-GiST index, with the
new range type SP-GiST opclass. There's some low-hanging fruit there, I
was able to reduce the index build time on a simple test case by about
20% with a few small changes.
I created a test table with:
create table range_te
2012/8/28 Albe Laurenz :
> Kohei KaiGai wrote:
>> It is a responsibility of FDW extension (and DBA) to ensure each
>> foreign-row has a unique identifier that has 48-bits width integer
>> data type in maximum.
>
For example, if primary key of the remote table is Text data type,
>>>
Kohei KaiGai wrote:
> It is a responsibility of FDW extension (and DBA) to ensure each
> foreign-row has a unique identifier that has 48-bits width integer
> data type in maximum.
>>> For example, if primary key of the remote table is Text data type,
>>> an idea is to use a hash table
2012/8/27 Shigeru HANADA :
> Kaigai-san,
>
> On Thu, Aug 23, 2012 at 2:10 PM, Kohei KaiGai wrote:
>> The patched portion at contrib/file_fdw.c does not make sense
>> actually. It just prints messages for each invocation.
>> It is just a proof-of-concept to show possibility of implementation
>> bas
2012/8/27 Albe Laurenz :
> Kohei KaiGai wrote:
>> 2012/8/25 Robert Haas :
>>> On Thu, Aug 23, 2012 at 1:10 AM, Kohei KaiGai
> wrote:
It is a responsibility of FDW extension (and DBA) to ensure each
foreign-row has a unique identifier that has 48-bits width integer
data type in maxim
On Tue, Aug 28, 2012 at 6:13 AM, Greg Smith wrote:
> After staring at all the examples I generated again, I think Bruce is right
> that the newer format he's suggesting is better. I know I never thought
> about whether reordering for easier interpretation made sense before, and
> I'd also guess "
82 matches
Mail list logo
