On 2011-01-06 03:10, Robert Haas wrote:
On Wed, Jan 5, 2011 at 3:22 PM, Jesper Krogh wrote:
Given a crash-safe visibility map, what purpuse does the PD_ALL_VISIBLE bit
serve?
If we modify a page on which PD_ALL_VISIBLE isn't set, we don't
attempt to update the visibility map. In theory, this
(2011/01/06 14:28), Robert Haas wrote:
> 2011/1/5 KaiGai Kohei:
>> The attached patch is the modular version of SE-PostgreSQL (take.2).
>
> I'm reading through the documentation and so far it looks pretty
> reasonable. But I have some questions and suggested changes, of
> course. :-)
>
Thanks f
On Thu, Jan 06, 2011 at 12:24:19AM -0500, Robert Haas wrote:
> I still think you're better off focusing first on the case where we
> can skip the whole nine yards, and doing this stuff as a follow-on
> patch. Trying to do too many things, especially possibly
> controversial stuff, especially in th
2011/1/5 KaiGai Kohei :
> The attached patch is the modular version of SE-PostgreSQL (take.2).
I'm reading through the documentation and so far it looks pretty
reasonable. But I have some questions and suggested changes, of
course. :-)
1. Why is sepgsql the right name for this module, as oppose
On Wed, Jan 5, 2011 at 11:26 PM, Noah Misch wrote:
> On Thu, Dec 30, 2010 at 08:35:34PM -0500, Noah Misch wrote:
>> On Thu, Dec 30, 2010 at 12:57:45AM -0500, Robert Haas wrote:
>> > On Thu, Dec 30, 2010 at 12:24 AM, Noah Misch wrote:
>> > > On Wed, Dec 29, 2010 at 11:14:37PM -0500, Robert Haas wr
On Wed, Jan 5, 2011 at 11:08 PM, Tom Lane wrote:
> Or we could take the approach somebody was just espousing about
>
>> Our job is to prevent the user from *accidentally*
>> shooting themselves in the foot.
I don't see how you can compare those two cases with a straight face.
In the FOREIGN KEY N
On tis, 2011-01-04 at 22:24 -0500, Robert Haas wrote:
> > Just to be clear: are we saying that "CREATE ROLE foo SUPERUSER"
> > should grant both superuser and replication, as well as the default
> > "postgres" user also having replication as well?
>
> I think that's what we're saying.
So now supe
On mån, 2011-01-03 at 11:20 -0500, Tom Lane wrote:
> You might want to reflect on rolcatupdate a bit before asserting that
> there are no cases where privileges are ever denied to superusers.
Arguably, the reason that that is hardly documented and slightly
deprecated is that the underlying design
On Thu, Dec 30, 2010 at 08:35:34PM -0500, Noah Misch wrote:
> On Thu, Dec 30, 2010 at 12:57:45AM -0500, Robert Haas wrote:
> > On Thu, Dec 30, 2010 at 12:24 AM, Noah Misch wrote:
> > > On Wed, Dec 29, 2010 at 11:14:37PM -0500, Robert Haas wrote:
> > >> I think for any pair of types (T1, T2) we sho
On 01/05/2011 11:08 PM, Tom Lane wrote:
If they want to deliberately shoot themselves in the foot by hosing the
login system like that, it's not our job to prevent it. But it's not
our job to try to work around it, either.
I think this is especially true in this cas
Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Jan 5, 2011 at 9:44 PM, Bruce Momjian wrote:
> >> I think pg_dumpall would have failed with this setup too, so I don't see
> >> this as a pg_upgrade bug, nor something that I am willing to risk adding
> >> to pg_upgrade.
>
> > If adding RESET SES
Robert Haas writes:
> On Wed, Jan 5, 2011 at 9:44 PM, Bruce Momjian wrote:
>> I think pg_dumpall would have failed with this setup too, so I don't see
>> this as a pg_upgrade bug, nor something that I am willing to risk adding
>> to pg_upgrade.
> If adding RESET SESSION AUTHORIZATION fixes the b
Robert Haas wrote:
> On Wed, Jan 5, 2011 at 9:44 PM, Bruce Momjian wrote:
> > I think pg_dumpall would have failed with this setup too, so I don't see
> > this as a pg_upgrade bug, nor something that I am willing to risk adding
> > to pg_upgrade.
>
> If adding RESET SESSION AUTHORIZATION fixes th
On Wed, Jan 5, 2011 at 9:44 PM, Bruce Momjian wrote:
> I think pg_dumpall would have failed with this setup too, so I don't see
> this as a pg_upgrade bug, nor something that I am willing to risk adding
> to pg_upgrade.
If adding RESET SESSION AUTHORIZATION fixes the bug, I think we should
consid
Robert Haas wrote:
> On Mon, Dec 13, 2010 at 12:59 AM, Rob Wultsch wrote:
> > On Sun, Dec 12, 2010 at 7:24 PM, Andrew Dunstan wrote:
> >> In fact it's possible now to disable FK enforcement, by disabling the
> >> triggers. It's definitely a footgun though. Just the other day I was asked
> >> how
Florian Pflug wrote:
> Hi
>
> I've just ran into a problem while upgrading from 8.4 to 9.0.
>
> pg_upgrade aborted during the step "Adding support functions to new
> cluster" with "ERROR: permission denied for language c" error.
> Unfortunately, the log didn't include the name of the database wh
Robert Haas wrote:
> On Wed, Jan 5, 2011 at 12:21 PM, Bruce Momjian wrote:
> > The psql manual page mentions lo_insert:
> >
> > ? ? ? ? ? LASTOID
> > ? ? ? ? ? ? ? The value of the last affected OID, as returned
> > --> ? ? ? ? ? ?from an INSERT or lo_insert command. This variable
> > ? ? ? ? ? ?
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> > > Tom Lane wrote:
> > >> That isn't going to work. At least not unless you start trying to force
> > >> roles to have the same OIDs in the new installation.
> >
> > > If so I can use the CREATE ROLE ... SYSID clause when doing
On Wed, Jan 5, 2011 at 12:21 PM, Bruce Momjian wrote:
> The psql manual page mentions lo_insert:
>
> LASTOID
> The value of the last affected OID, as returned
> --> from an INSERT or lo_insert command. This variable
> is only guaranteed to be valid
On Wed, Jan 5, 2011 at 3:22 PM, Jesper Krogh wrote:
> Given a crash-safe visibility map, what purpuse does the PD_ALL_VISIBLE bit
> serve?
If we modify a page on which PD_ALL_VISIBLE isn't set, we don't
attempt to update the visibility map. In theory, this is an important
optimization to reduce
On Wed, Jan 5, 2011 at 6:25 PM, Josh Berkus wrote:
> On 1/5/11 3:14 PM, Robert Haas wrote:
>> I think that's probably a dead end - just to take one example, if you
>> don't sync often enough, the standby might have transaction ID
>> wraparound problems. Autovacuum on the master will prevent that
2011/1/6 Jeff Davis :
> Even if add and subtract were associated with a range type, there's no
> way to tell which range type to pick given the window function syntax
> (multiple range types could be defined over the same subtype).
>
> I think the interface question should be addressed more directl
Hello,
I have added my common table expressions docpatch to the 2011-01 commitfest:
https://commitfest.postgresql.org/action/patch_view?id=476
I think that we need to get this resolved.
--
Regards,
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On 1/5/11 3:14 PM, Robert Haas wrote:
> I think that's probably a dead end - just to take one example, if you
> don't sync often enough, the standby might have transaction ID
> wraparound problems. Autovacuum on the master will prevent that for
> permanent tables, but not for an only-occasionally-
On Wed, Jan 5, 2011 at 3:58 PM, Josh Berkus wrote:
>> Hm- if the unlogged tables are being used as HTTP transient state storage,
>> it would be handy to have that (admittedly non-essential) data on the
>> standby when it becomes master, even if there are no guarantees surrounding
>> the data be
> This is a great use case for user level tracing support. Add a probe
> around these bits, and you can capture the information when you need
> it.
Yeah, would be lovely if user-level tracing existed on all platforms.
--
-- Josh Berkus
On Wed, Jan 5, 2011 at 2:27 PM, Josh Berkus wrote:
>
>> If you could gather more info on whether this logging catches the
>> problem cases you're seeing, that would really be the right test for the
>> patch's usefulness. I'd give you solid 50/50 odds that you've correctly
>> diagnosed the issue,
Magnus Hagander writes:
>> Compression in libpq would be a nice way to solve it, later.
>
> Yeah, I'm pretty much set on postponing that one.
+1, in case it was not clear for whoever's counting the votes :)
>> What about pg_streamrecv | gzip > …, which has the big advantage of
>
> That's part of
Josh Berkus writes:
> It would be useful (this would allow per-standby buffer tables, for that
> matter), but it would also be tremendously difficult. Seems worthy of a
> TODO, though.
Don't we have anything covering xid-less tables in the TODO already? The
read-only tables "compressions" of rem
Robert Haas writes:
> diff --git a/src/backend/commands/alter.c b/src/backend/commands/alter.c
> index 6a9b21d..1c6ae02 100644
>
> I actually haven't figured out exactly under what circumstances that
I think it's for git am -3
http://www.kernel.org/pub/software/scm/git/docs/git-am.html
But I
On Wed, Jan 5, 2011 at 22:58, Dimitri Fontaine wrote:
> Magnus Hagander writes:
>> Attached is an updated streaming base backup patch, based off the work
>
> Thanks! :)
>
>> * Compression: Do we want to be able to compress the backups server-side? Or
>> defer that to whenever we get compression
Magnus Hagander writes:
> Attached is an updated streaming base backup patch, based off the work
Thanks! :)
> * Compression: Do we want to be able to compress the backups server-side? Or
> defer that to whenever we get compression in libpq? (you can still tunnel it
> through for example SSH
Jeff Janes writes:
> ("top" doesn't distinguish between memory that has been requested but
> never accessed, versus memory that has been accessed and then truly
> swapped out to disk. So unless you first let it run to steady-state
> before applying pressure, it is hard to interpret the results.)
> Hm- if the unlogged tables are being used as HTTP transient state storage, it
> would be handy to have that (admittedly non-essential) data on the standby
> when it becomes master, even if there are no guarantees surrounding the data
> beyond "it looked like this at some point". Since the tab
On 2010-11-30 05:57, Robert Haas wrote:
Last week, I posted a couple of possible designs for making the
visibility map crash-safe, which did not elicit much comment. Since
this is an important prerequisite to index-only scans, I'm trying
again.
The logic seems to be:
* If the visibillity map
On Wed, Jan 5, 2011 at 3:06 PM, Robert Haas wrote:
> On Wed, Jan 5, 2011 at 3:00 PM, Simon Riggs wrote:
>> On Mon, 2011-01-03 at 23:13 -0500, Robert Haas wrote:
>>
>>> > Hmmm, my earlier code took xmax only if xmax > xmin. That was wrong;
>>> > what I have now is better, but your point is there m
On Wed, 2011-01-05 at 10:41 -0800, David Fetter wrote:
> On Thu, Jan 06, 2011 at 02:25:01AM +0900, Hitoshi Harada wrote:
> > For any type to calculate boundary based on RANGE clause in window
> > functions, we need some type interface mechanism in the core to know
> > how to add / subtract values t
On Wed, Jan 5, 2011 at 3:00 PM, Simon Riggs wrote:
> On Mon, 2011-01-03 at 23:13 -0500, Robert Haas wrote:
>
>> > Hmmm, my earlier code took xmax only if xmax > xmin. That was wrong;
>> > what I have now is better, but your point is there may be an even better
>> > truth. I'll think on that a litt
On Mon, 2011-01-03 at 23:13 -0500, Robert Haas wrote:
> > Hmmm, my earlier code took xmax only if xmax > xmin. That was wrong;
> > what I have now is better, but your point is there may be an even better
> > truth. I'll think on that a little more.
I remember that I thought some more on this and
On Jan 5, 2011, at 2:37 PM, Robert Haas wrote:
> On Wed, Jan 5, 2011 at 2:36 PM, Simon Riggs wrote:
>> The lock strength selected on the master doesn't need to be the same as
>> the lock strength on the standby. You could quite easily generate AEL
>> lock records to send to standby, without actu
On Wed, Jan 5, 2011 at 2:36 PM, Simon Riggs wrote:
> The lock strength selected on the master doesn't need to be the same as
> the lock strength on the standby. You could quite easily generate AEL
> lock records to send to standby, without actually taking that lock level
> on the master.
True.
>
Robert Haas writes:
> My understanding of the consensus is that it wasn't felt necessary for
> the purpose for which it was proposed. I think it could be
> re-proposed with a different argument and very possibly accepted.
Sure. I'd still prefer us to adopt the solution I've been promoting,
obvi
On Tue, 2011-01-04 at 21:41 -0500, Robert Haas wrote:
> 6. If wal_level != minimal, XLOG every page of every fork except the
> init fork, for both the table and the associated indexes. (Note that
> this step also requires an AccessExclusiveLock rather than some weaker
> lock, because of the arbitr
> If you could gather more info on whether this logging catches the
> problem cases you're seeing, that would really be the right test for the
> patch's usefulness. I'd give you solid 50/50 odds that you've correctly
> diagnosed the issue, and knowing for sure would make advocating for this
> log
David Fetter writes:
> The syntax by itself does nothing, but the underlying capability gives
> users:
Ok, now I understand that the syntax you proposed was a shortcut for an
I-want-it-all request :)
> - The ability to have versions of software on different databases on
> the same system.
>
>
On Wed, Jan 5, 2011 at 2:02 PM, Josh Berkus wrote:
> Note that the conversion both ways can be worked around with the
> CREATE/ALTER TABLE dosiedo, so I don't think either of these is critical
> for 9.1. Unless you feel like working on them, of course.
As I said in my OP, I don't intend to work
On 1/4/11 6:41 PM, Robert Haas wrote:
> Going the other direction ought to be possible too, although it seems
> somewhat less useful.
Actually, it's more useful; many people who *upgrade* to 9.1 will wand
to convert one or two of their tables to unlogged.
Note that the conversion both ways can be
On Thu, Jan 06, 2011 at 02:25:01AM +0900, Hitoshi Harada wrote:
> 2011/1/5 Jeff Davis :
> > On Tue, 2011-01-04 at 23:04 +0900, Hitoshi Harada wrote:
> >> > CREATE TYPE numrange
> >> > AS RANGE (SUBTYPE=numeric, SUBTYPE_CMP=numeric_cmp);
> >>
> >> I am interested in how you define increment/decr
On Jan 5, 2011, at 10:05 AM, Robert Haas wrote:
>> There's no consensus to publish a bakend \i like function. So there's
>> no support for this upgrade script organizing you're promoting. Unless
>> the consensus changes again (but a commit has been done).
>
> My understanding of the consensus i
On Wed, Jan 5, 2011 at 12:59 PM, Andrew Dunstan wrote:
> I've abandoned the use of an external diff program for git. If I need
> context diffs I produce them by piping normal git diff output through
> "filterdiff --format=context".
One possible disadvantage of that it strips out this stuff:
diff
On Tue, Jan 4, 2011 at 2:48 PM, Dimitri Fontaine wrote:
> "David E. Wheeler" writes:
>> As Tom pointed out, you can do the same with naming conventions by having
>> scripts \i each other as appropriate.
>
> This is a deprecated idea, though. We're talking about the
> pg_execute_from_file() patc
On 01/05/2011 12:33 PM, Magnus Hagander wrote:
It's actually the same patch as before with the corrupted line-endings
parsed out.
"git diff master VS2010> ../VS2010.patch" reproduceabyl generates those on
my (windows) system when I use git-external-diff configured as described in
http://wiki.
2011/1/5 Florian Pflug :
> On Jan5, 2011, at 15:17 , Pavel Stehule wrote:
>> 2011/1/5 Florian Pflug :
>>> How so? You'd still be able to get the last element by simply writing
>>>
>>> array_relative(some_array, array[-1]).
>>>
>>> Or, if we made the function variadic, by writing
>>>
>>> array_rel
On Mon, Jan 3, 2011 at 16:45, Brar Piening wrote:
> On Mon, 3 Jan 2011 10:44:19 +0100, Magnus Hagander
> wrote:
>>
>> Yeah, it looks that way - it's missing the ordering of the contrib
>> I'll run it once for that now, and then please rebase your
>> patch on top of that - makes it easier to revie
2011/1/5 Jeff Davis :
> On Tue, 2011-01-04 at 23:04 +0900, Hitoshi Harada wrote:
>> > CREATE TYPE numrange
>> > AS RANGE (SUBTYPE=numeric, SUBTYPE_CMP=numeric_cmp);
>>
>> I am interested in how you define increment/decrement operation of
>> range value in discrete types. The window functions an
2011/1/5 Jeff Davis :
> On Tue, 2011-01-04 at 23:04 +0900, Hitoshi Harada wrote:
>> > CREATE TYPE numrange
>> > AS RANGE (SUBTYPE=numeric, SUBTYPE_CMP=numeric_cmp);
>>
>> I am interested in how you define increment/decrement operation of
>> range value in discrete types. The window functions an
The psql manual page mentions lo_insert:
LASTOID
The value of the last affected OID, as returned
-->from an INSERT or lo_insert command. This variable
is only guaranteed to be valid until after the
result of the next SQL command h
The attached, applied patch clarifies pg_upgrade's creation of the map
file structure. It also cleans up pg_dump's calling of
pg_upgrade_support functions.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for ev
On Jan5, 2011, at 15:17 , Pavel Stehule wrote:
> 2011/1/5 Florian Pflug :
>> How so? You'd still be able to get the last element by simply writing
>>
>> array_relative(some_array, array[-1]).
>>
>> Or, if we made the function variadic, by writing
>>
>> array_relative(some_array, -1).
>
> Sorr
Tom Lane wrote:
> Bruce Momjian writes:
> > Tom Lane wrote:
> >> That isn't going to work. At least not unless you start trying to force
> >> roles to have the same OIDs in the new installation.
>
> > If so I can use the CREATE ROLE ... SYSID clause when doing a binary
> > upgrade.
>
> Oh, I ha
Bruce Momjian writes:
> Tom Lane wrote:
>> That isn't going to work. At least not unless you start trying to force
>> roles to have the same OIDs in the new installation.
> If so I can use the CREATE ROLE ... SYSID clause when doing a binary
> upgrade.
Oh, I had forgotten we still had that wart
On Wed, Jan 05, 2011 at 10:19:23AM +0100, Dimitri Fontaine wrote:
> David Fetter writes:
> > One could imagine that an extension was updated more quickly than
> > PostgreSQL major versions come out, or at least not at the exact same
> > time.
>
> Sure, but I don't see what your proposed syntax is
Tom Lane wrote:
> Bruce Momjian writes:
> > The last patch fixes a problem where I was not migrating
> > pg_largeobject_metadata and its index for 9.0+ migrations, which of
> > course would only affect migrations to 9.1 and 9.0 to 9.0 migrations, so
> > I backpatched that to 9.0.
>
> That isn't g
On 01/05/2011 02:54 PM, Magnus Hagander wrote:
[..]
Some remaining thoughts and must-dos:
* Compression: Do we want to be able to compress the backups server-side? Or
defer that to whenever we get compression in libpq? (you can still tunnel it
through for example SSH to get compression if
On Wed, Jan 5, 2011 at 7:48 AM, David Fetter wrote:
> On Wed, Jan 05, 2011 at 09:04:08AM -0500, Robert Haas wrote:
>> On Tue, Jan 4, 2011 at 10:56 PM, Rob Wultsch wrote:
>> > 1. Could the making a table logged be a non-exclusive lock if the
>> > ALTER is allowed to take a full checkpoint?
>>
>> N
On Wed, Jan 05, 2011 at 09:04:08AM -0500, Robert Haas wrote:
> On Tue, Jan 4, 2011 at 10:56 PM, Rob Wultsch wrote:
> > 1. Could the making a table logged be a non-exclusive lock if the
> > ALTER is allowed to take a full checkpoint?
>
> No, that doesn't solve either of the two problems I describe
Bruce Momjian writes:
> The last patch fixes a problem where I was not migrating
> pg_largeobject_metadata and its index for 9.0+ migrations, which of
> course would only affect migrations to 9.1 and 9.0 to 9.0 migrations, so
> I backpatched that to 9.0.
That isn't going to work. At least not un
2011/1/5 Florian Pflug :
> On Jan5, 2011, at 13:08 , Pavel Stehule wrote:
>> 2011/1/5 Florian Pflug :
>>> On Jan5, 2011, at 10:25 , Peter Eisentraut wrote:
On sön, 2011-01-02 at 12:47 +0100, Florian Pflug wrote:
> The only way around that would be to introduce magic constants "lower",
>>>
On Wed, Jan 5, 2011 at 12:54 AM, Jeff Davis wrote:
> On Tue, 2011-01-04 at 16:45 -0800, Josh Berkus wrote:
>> On 1/4/11 10:18 AM, Jeff Davis wrote:
>> > The main drawback here is that only a select group of people will be
>> > defining discrete range types at all, because it would require them to
On Wed, Jan 5, 2011 at 8:24 AM, Magnus Hagander wrote:
> Ok, done and applied.
Thanks.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://
On Tue, Jan 4, 2011 at 10:56 PM, Rob Wultsch wrote:
> 1. Could the making a table logged be a non-exclusive lock if the
> ALTER is allowed to take a full checkpoint?
No, that doesn't solve either of the two problems I described, unfortunately.
> 2. Unlogged to logged has giant use case.
Agree.
Attached is an updated streaming base backup patch, based off the work
that Heikki
started. It includes support for tablespaces, permissions, progress
reporting and
some actual documentation of the protocol changes (user interface
documentation is
going to be depending on exactly what the frontend
On Jan5, 2011, at 13:08 , Pavel Stehule wrote:
> 2011/1/5 Florian Pflug :
>> On Jan5, 2011, at 10:25 , Peter Eisentraut wrote:
>>> On sön, 2011-01-02 at 12:47 +0100, Florian Pflug wrote:
The only way around that would be to introduce magic constants "lower",
"upper" that
can be used
On Wed, Jan 5, 2011 at 02:32, Itagaki Takahiro
wrote:
> On Wed, Jan 5, 2011 at 04:56, Heikki Linnakangas
> wrote:
>>> I think pg_stat_replication is better than pg_stat_standby, but I'm
>>> still not convinced we shouldn't go with the obvious
>>> pg_stat_walsenders.
>>
>> How about pg_stat_replic
On Wed, Jan 5, 2011 at 04:24, Robert Haas wrote:
> On Mon, Jan 3, 2011 at 5:50 PM, Magnus Hagander wrote:
>> On Mon, Jan 3, 2011 at 17:23, Robert Haas wrote:
>>> On Mon, Jan 3, 2011 at 11:20 AM, Tom Lane wrote:
Robert Haas writes:
> On the other hand, the REPLICATION privilege is deny
On Wed, Jan 5, 2011 at 07:55, Greg Smith wrote:
> a bit of work in userland, I don't see this even being justified as an INFO
> or LOG level message. Anytime I can script a SQL-level monitor for
> something that's easy to tie into Nagios or something, I greatly prefer that
> to log file scrapi
2011/1/5 Florian Pflug :
> On Jan5, 2011, at 10:25 , Peter Eisentraut wrote:
>> On sön, 2011-01-02 at 12:47 +0100, Florian Pflug wrote:
>>> The only way around that would be to introduce magic constants "lower",
>>> "upper" that
>>> can be used within index expressions and evaluate to the indexed
David Fetter writes:
> One could imagine that an extension was updated more quickly than
> PostgreSQL major versions come out, or at least not at the exact same
> time.
Sure, but I don't see what your proposed syntax is giving us here.
Currently the new version you're upgraded to is the one insta
On Wed, Jan 5, 2011 at 19:24, Shigeru HANADA wrote:
> 2) foreign_scan.patch includes ForeignScan executor node and
> FdwRoutine interface
I can see now Iterate() callback is called in per-tuple memory context.
I'll adjust copy from API for the change. We don't need to export the
executor state in
On Jan5, 2011, at 10:25 , Peter Eisentraut wrote:
> On sön, 2011-01-02 at 12:47 +0100, Florian Pflug wrote:
>> The only way around that would be to introduce magic constants "lower",
>> "upper" that
>> can be used within index expressions and evaluate to the indexed dimension's
>> lower
>> and up
Hello
2011/1/5 Peter Eisentraut :
> On sön, 2011-01-02 at 12:47 +0100, Florian Pflug wrote:
>> > Here's a patch to add support for negative index values in fetching
>> > elements from an array.
>>
negative arguments for array can be really strange
>> That won't work. In SQL, array indices don't
ATE/ALTER
FOREIGN DATA WRAPPER
2) foreign_scan.patch includes ForeignScan executor node and
FdwRoutine interface
Regards,
--
Shigeru Hanada
20110105-fdw_handler.patch.gz
Description: Binary data
20110105-foreign_scan.patch.gz
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsq
On sön, 2011-01-02 at 12:47 +0100, Florian Pflug wrote:
> > Here's a patch to add support for negative index values in fetching
> > elements from an array.
>
> That won't work. In SQL, array indices don't necessarily start with 0 (or 1,
> or *any*
> single value).
FYI, this is true for PostgreS
83 matches
Mail list logo
