On Thu, Jan 8, 2015 at 7:02 PM, Kevin Grittner wrote:
> Ashutosh Bapat wrote:
> > On Wed, Jan 7, 2015 at 9:50 PM, Kevin Grittner
> wrote:
>
> >> Also, as previously mentioned, it must behave in some reasonable
> >> way if a database is not configured to suppo
isting 2PC
infrastructure or not. My initial reaction is no, since 2PC persists
information about local transaction including locked objects, WALs (?) in
pg_twophase directory, which is not required for a distributed transaction.
But rest of the mechanism like the manner of processing the records during
normal processing and recovery looks very useful.
--
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
lel query infrastructure being built by
Robert or to do something like parallel seq scan? That will work, not just
for Postgres FDW but all the FDWs.
>
> > I think, we need some data which shows the speed up by this patch. You
> may
> > construct a case, where a single query involved multiple foreign scans,
> and
> > we can check what is the speed up obtained against the number of foreign
> > scans.
>
> Agreed, I'll show you some such figures afterwards.
>
> > > * Concerns about this patch.
> > >
> > > - This breaks the assumption that scan starts at ExecForeignScan,
> > > not ExecInitForeignScan, which might cause some problem.
> > >
> > >
> > This should be fine as long as it doesn't have any side effects like
> > sending query during EXPLAIN (which has been taken care of in this
> patch.)
> > Do you think, we need any special handling for PREPAREd statements?
>
> I suppose there's no difference between PREAPREd and
> not-PREPAREDd at the level of FDW.
>
In case of Prepared statements, ExecInit is called at the end of planning,
without subsequent execution like the case of EXPLAIN. I see that the patch
handles EXPLAIN well, but I didn't see any specific code for PREPARE.
>
> regards,
>
> --
> Kyotaro Horiguchi
> NTT Open Source Software Center
>
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
ed resource that can be managed and
> reported on and becomes considerably more predictable.
> >
>
> Yeah, it is good idea to maintain shared worker pool, but it seems
> to me that for initial version even if the workers are not shared,
> then also it is meaningful to make parallel sequential scan work.
>
>
> With Regards,
> Amit Kapila.
> EnterpriseDB: http://www.enterprisedb.com
>
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
e relation (in this case,
> > the partition) NOT a block range. But I guess the infrastructure is
> > generalized enough that we could make that work. Related then would be
> > an equivalent of ScanKey for the partitioning case. Just as ScanKeyData
> > has correspondence wit
On Thu, Jul 7, 2011 at 9:41 PM, Robert Haas wrote:
> On Thu, Jul 7, 2011 at 3:05 AM, Ashutosh Bapat
> wrote:
> > I noticed that the test alter_table.sql is creating two tables tab1 and
> tab2
> > and it's not dropping it. Any test which follows this test and tries
I think you misunderstood what I was saying. I wanted take out the
> cleanup parts out of all test cases and make it a choice whether to run
> them. Right now we have a lot of test cases that clean up after
> themselves, which is useful in some cases (testing the cleaning, for one
> thing), but not useful for 2. and 3.
>
>
>
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company
folded
into queries, it looks like parameter values stored in EState are never
used.
Is this correct? Or somewhere we use those parameter values?
--
Best Wishes,
Ashutosh Bapat
EntepriseDB Corporation
The Enterprise Postgres Company
On Tue, Aug 2, 2011 at 3:45 PM, Heikki Linnakangas <
heikki.linnakan...@enterprisedb.com> wrote:
> On 02.08.2011 12:54, Ashutosh Bapat wrote:
>
>> Hi All,
>> I am looking at usage of bound parameters.
>>
>> In functions SPI_cursor_open_with_args() and SPI_curso
> >> * should match what ExecCheckRTEPerms() does. If we fail due
> >> to lack of
> >> * permissions, the query would have failed at runtime anyway.
> >> */
> >> - if (fpinfo->use_remote_estimate)
> >> - {
> >> - RangeTblEntry *rte = planner_rt_fetch(baserel->relid,
> root);
> >> - Oid userid = rte->checkAsUser ?
> >> rte->checkAsUser : GetUserId();
> >> -
> >> - fpinfo->user = GetUserMapping(userid,
> fpinfo->server->serverid);
> >> - }
> >> - else
> >> - fpinfo->user = NULL;
> >> + rte = planner_rt_fetch(baserel->relid, root);
> >> + fpinfo->userid = rte->checkAsUser ? rte->checkAsUser :
> GetUserId();
> >>
> >> So, wait a minute, remote estimates aren't optional any more?
> >
> > No, it seems to be removed accidentally. I’ll check the reason again
> though, but I’ll revert the change unless I find any problem.
> >
> > --
> > Shigeru HANADA
> > shigeru.han...@gmail.com
> >
> >
> >
> >
>
>
>
> --
> Shigeru HANADA
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
> --
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
hould fix the code not to wipe out bgw_notify_pid in the
code above (may be change PostmasterMarkPIDForWorkerNotify() to scan the
list of other background workers as well)?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
1 and 2 might be better than having yet another init fork.
1. http://www.postgresql.org/message-id/533d457a.4030...@vmware.com
>
> Regards,
>
> --
> Fabrízio de Royes Mello
> Consultoria/Coaching PostgreSQL
> >> Timbira: http://www.timbira.com.br
> >> Blog: http://fabriziomello.github.io
> >> Linkedin: http://br.linkedin.com/in/fabriziomello
> >> Twitter: http://twitter.com/fabriziomello
> >> Github: http://github.com/fabriziomello
>
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
}
>
> Console.WriteLine for par1 returns 2. Console.Writline for Result returns
> nothing.
>
>
>
> --
> View this message in context:
> http://postgresql.nabble.com/C-reading-result-from-a-function-tp5856560.html
> Sent from the PostgreSQL - hackers mailing list ar
stration. So that would be a bug.
> >
> > Does this help you any?
>
> Well, it sounds like we at least need to think about making it
> consistently depend on shmem-access rather than database-connection.
> I'm less sure what to do with workers that have not ev
On Wed, Jul 8, 2015 at 1:27 AM, Fabrízio de Royes Mello <
fabriziome...@gmail.com> wrote:
>
> On Fri, Jul 3, 2015 at 9:29 AM, Ashutosh Bapat <
> ashutosh.ba...@enterprisedb.com> wrote:
> >
> >
> > On Fri, Jul 3, 2015 at 4:48 PM, Fabrízio de Royes M
ing down the join. Although, I haven't tried the exact query given in
the report. Please let me know if the patch fixes issue with that query as
well.
The query generated by sqlsmith doesn't seem to return any result since it
assigns 31 to subq_0.c0 and the WHERE clause checks 92 =subq_0.c0.
ush-down joins
in this case, we have two solutions
1. Build queries with subqueries at the time of deparsing. Thus a base
relation or join has to include placeholders while being deparsed as a
subquery. This means that the deparser should deparse expression
represented by the placeholder. This may not
On Tue, Jun 7, 2016 at 4:07 PM, Amit Langote
wrote:
> On 2016/06/07 19:13, Ashutosh Bapat wrote:
> > I thought, columns of inner relation will be set to null during
> projection
> > from ForeignScan for joins. But I was wrong. If we want to push-down
> joins
> >
at 7:47 PM, Ashutosh Bapat wrote:
> > On Tue, Jun 7, 2016 at 4:07 PM, Amit Langote wrote:
> >> On 2016/06/07 19:13, Ashutosh Bapat wrote:
> >> > So, your patch looks to be the correct approach (even after we support
> >> > deparsing subqueries). Can you please
On Wed, Jun 8, 2016 at 12:25 PM, Amit Langote wrote:
> On 2016/06/08 14:13, Ashutosh Bapat wrote:
> > On Tue, Jun 7, 2016 at 6:19 PM, Amit Langote wrote:
> >> On Tue, Jun 7, 2016 at 7:47 PM, Ashutosh Bapat wrote:
> >>> Looks good to me. If we add a column from the
ion.c:747
>
> [...]
>
> I made a mistake in the last version of the patch which caused a relcache
> field to be pfree'd unexpectedly. Attached updated patches.
>
> Thanks,
> Amit
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
>
rpose for which I added the Assert, but in a
better manner. May be the error message can read "non-Var
nodes/targets/expressions not expected in target list". I am not sure what
do we call individual (whole) members of target list.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
://users.cs.duke.edu/~shivnath/papers/sigmod295-herodotou.pdf
[3]. https://users.cs.duke.edu/~shivnath/tmp/paqo_draft.pdf
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
partitioned_join.out
Description: Binary data
\set num_samples 100
drop table t1 cascade;
drop table t2
artitioned table by range on expression chr(a) it
works.
On Thu, Jun 9, 2016 at 7:20 AM, Amit Langote
wrote:
> On 2016/06/08 22:22, Ashutosh Bapat wrote:
> > On Mon, May 23, 2016 at 3:35 PM, Amit Langote wrote
> >>
> >> [...]
> >>
> >> I made a
something of the
pre-8.3
2261 * behavior that many types had implicit (yipes!) casts to
text.
2262 */
PFA the patch with the cast to text. This is probably uglier than expected,
but I don't know any better test to find nullness of a record, the way we
want here. The patch als
D". IMO I think that that would
> be much simpler than Ashutosh's approach.
>
>
A foreign table can have a view, a regular table, another foreign table or
a materialised view a its target. A view does not support any of the system
columns, so none of them are available.
--
Best
ids
(which isn't a big deal I guess). That's something more than necessary for
fixing the bug, which is the focus in beta stage right now.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
also address this by replacing the whole-row reference in the IS NOT NULL
> condition in that conversion with the system column reference.
>
> That would not work again as the system column reference would make sense
locally but may not be available at the foreign server e.g. foreign table
targeting a view a tableoid is requested.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Wed, Jun 22, 2016 at 3:57 PM, Etsuro Fujita
wrote:
> On 2016/06/22 18:16, Ashutosh Bapat wrote:
>
>> On Wed, Jun 22, 2016 at 2:26 PM, Etsuro Fujita
>> mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
>>
>
> I think we could address this in another
a
record is null and not null in the way we want (as described upthread). I
didn't find any quickly. Do you have any suggestions?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Fri, Jun 24, 2016 at 1:59 PM, Amit Langote wrote:
> On 2016/06/24 15:44, Ashutosh Bapat wrote:
> >>
> >> I think the proposed idea of applying record::text explicit coercion to
> a
> >> whole-row reference in the IS NOT NULL condition in the CASE WHEN
> >
t1_l SELECT i, to_char(i, 'FM00'), i FROM
generate_series(1, 600, 2) i;
CREATE TABLE upt1_l AS SELECT * FROM pt1_l;
The last statement gives error "ERROR: cache lookup failed for function
0". Let me know if this problem is reproducible.
On Thu, Jun 9, 2016 at 7:20 AM, Amit Lan
alified; otherwise, qualify.
*/
static char *
deparse_type_name(Oid type_oid, int32 typemod)
{
if (is_builtin(type_oid))
return format_type_with_typemod(type_oid, typemod);
else
return format_type_with_typemod_qualified(type_oid, typemod);
}
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
case reproducing the bug here? It would be good to
include that test in the regression.
There is a always a possibility that a user would create a table (which can
be used as target for the foreign table) with column named 'wholerow', in
which case s/he will get confused with this error messag
On Tue, Jun 28, 2016 at 9:00 AM, Etsuro Fujita
wrote:
> On 2016/06/27 18:56, Ashutosh Bapat wrote:
>
>> On Mon, Jun 27, 2016 at 3:06 PM, Etsuro Fujita
>> mailto:fujita.ets...@lab.ntt.co.jp>> wrote:
>>
>
> I found another bug in error handling of whole-ro
On Tue, Jun 28, 2016 at 11:43 AM, Etsuro Fujita wrote:
> On 2016/06/28 13:53, Ashutosh Bapat wrote:
>
>> Ideally, we should point out the specific column that faced the
>> conversion problem and report it, instead of saying the whole row
>> reference conversion caused t
ill be tempted to create more instances of
schema-qualification. I think we should revert the schema qualification.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Tue, Jun 28, 2016 at 12:52 PM, Etsuro Fujita wrote:
> On 2016/06/28 15:23, Ashutosh Bapat wrote:
>
>> The wording "column "whole-row reference ..." doesn't look good.
>> Whole-row reference is not a column. The error context itself should be
>>
On Fri, Jul 1, 2016 at 7:45 PM, Robert Haas wrote:
> On Tue, Jun 28, 2016 at 8:20 AM, Ashutosh Bapat
> wrote:
> >> > postgres_fdw resets the search path to pg_catalog while opening
> >> > connection
> >> > to the server. The reason behind this is
are
valid, but then onwards they are restamped with the varno of the first
partition.
Please add testcases to your patch to catch such types of issues.
On Mon, Jun 27, 2016 at 3:56 PM, Amit Langote wrote:
>
> Hi Ashutosh,
>
> On 2016/06/24 23:08, Ashutosh Bapat wrote:
> > Hi
. If we do that, we might not set
hasForeignJoin flag in create_foreignscan_plan() when the user mapping for
pushed down join is invalid. That will keep FDWs which do not use user
mappings out of plan cache invalidation.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Thu, Jul 14, 2016 at 5:10 PM, Etsuro Fujita
wrote:
> On 2016/07/13 18:00, Ashutosh Bapat wrote:
>
>> To fix the first, I'd like to propose (1) replacing the existing
>> has_foreign_join flag in the CachedPlan data structure with a new
>> flag, say uses
On Thu, Jul 14, 2016 at 10:02 PM, Tom Lane wrote:
> Ashutosh Bapat writes:
> > Exactly, for a rare scenario, should we be penalizing large number of
> plans
> > or just continue to use a previously prepared plan when an optimal plan
> has
> > become available beca
>
>
Join between views on foreign tables or between foreign tables and views
containing foreign tables won't be rare. This feature is yet to be
released, so we don't know if PostgreSQL users would find it useful. But I
do see Oracle users joining views on dblink tables. I would guess same
would be the case in PostgreSQL. But I would like to hear from other
PostgreSQL FDW users. In such cases, being able to push down a join between
foreign tables across view boundaries will be useful.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
I am seeing following warning with this set of patches.
gram.y:4734:24: warning: assignment from incompatible pointer type [enabled
by default]
On Tue, Jul 5, 2016 at 10:18 AM, Amit Langote wrote:
> On 2016/07/04 21:31, Ashutosh Bapat wrote:
> > Hi Amit,
> > I observed that the
Sorry forgot to mention: this patch applies on top of the v7 patches posted
by Amit Langote on 27th June (
https://www.postgresql.org/message-id/81371428-bb4b-1e33-5ad6-8c5c51b52cb7%40lab.ntt.co.jp
).
On Tue, Jul 19, 2016 at 7:41 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com>
ike
Foreign Grouping, aggregation on ...
Foreign Join on ...
But then the question is a foreign scan node can be pushing down many
operations together e.g. join, aggregation, sort OR join aggregation and
windowing OR join and insert. How would we clearly convey this? May be we
say
Foreign Scan
operations: join on ..., aggregation, ...
That wouldn't be so great and might be clumsy for many operations. Any
better idea?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
", such as
> aggregation, window functions, distinct, order by, row locking, table
> modification, or combinations of them.
>
> "Scan" is a better word than "Processing". From plan's perspective it's
ultimately a Scan (on the data produced by the foreign server) and not
processing.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
pthread, we can see those relations from that, not the Relations line.
The join type is missing in that description.
> Also we can see the join tree structure from the deparsed query in the
> Remote SQL line.
The remote SQL has the names of the table on the foreign server. It does
not help to identify the local names.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
responding
partitions. We might be able to eliminate search in a given partition if
its lowest value is higher than the given value or its higher value is
lower than the given value.
On Thu, Jul 21, 2016 at 10:10 AM, Amit Langote <
langote_amit...@lab.ntt.co.jp> wrote:
> On 2016/07/19 22:53, A
On Fri, Aug 5, 2016 at 5:21 PM, Robert Haas wrote:
> On Fri, Aug 5, 2016 at 6:53 AM, Ashutosh Bapat
> wrote:
> > The lists for list partitioned tables are stored as they are specified by
> > the user. While searching for a partition to route tuple to, we compare
> it
>
;)} which are
essentially same, are represented in different ways. It makes matching
partitions for partition-wise join a bit tedius. We have to make sure that
the first array matches for both the joining relations and then make sure
that all the values belonging to the same partition for one table also
belong to the same partition in the other table. Some more complex logic
for matching subsets of lists for partition-wise join.
At least for straight forward partitioned table matching it helps to have
both these array look same independent of the user specification. From that
point of view, the partition be ordered by their lowest or highest list
values and the second array is the index in the ordered set. For both the
specifications above, the list will look like
[ 'a', 'b', 'd', 'e', f', 'h', 'i', 'l', 'm' ]
[1, 1, 2, 3, 3, 2, 3, 1, 2]
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
ge suggested above, it should be easy to check
partition-wise join compatibilty for simplest case. I agree that for
generic case it will be difficult. E.g. Table 1#: p3 {'a', 'e'}, p4{'a#',
'l'}, p2 {'b', 'f'}, p1 {'c', 'd'} being (INNER) joined with Table 2: p2
{'a', 'e'}, p1 {'b', 'f'}, p3 {'c', 'd'} assuming 'a'< 'a#' < 'b'; in this
case, we should be able to match p3-p2, p2-p1, p1-p3 for partition-wise
join, even though canonical representations of both partitions differ,
because of an extra partition in between.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
tuple routing. If the
> > algorithm I proposed above turns out to be too slow for matching
> > partitions, then we could keep both this representation and the
> > previous one. We are not limited to just one. But I don't think
> > that's likely to be the case.
>
> I agree. Let's see how the option 2 turns out.
>
> > Also, note that all of this presupposes we're doing range
> > partitioning, or perhaps list partitioning with a btree opclass. For
> > partitioning based on a hash opclass, you'd organize the data based on
> > the hash values rather than range comparisons.
>
> Yes, the current patch does not implement hash partitioning, although I
> have to think about how to support the hash case when designing the
> internal data structures.
>
>
> By the way, I am planning to start a new thread with the latest set of
> patches which I will post in a day or two. I have tried to implement all
> the bug fixes and improvements that have been suggested on this thread so
> far. Thanks to all those who reviewed and gave their comments. Please
> check this page to get a link to the new thread:
> https://commitfest.postgresql.org/10/611/
>
> Thanks,
> Amit
>
>
>
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
rt (0) end ((1/5) ...
Shouldn't we allow constant expressions here?
If this has been already discussed, please forgive me and point out the
relevant mail chain.
On Tue, Aug 9, 2016 at 12:48 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> What strikes me od
ar extracted out of a date column e.g. order_date.
They will find it convenient to use an expression (extract(month from
date)) as a partition key, instead of storing month or year as a separate
column.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
another question. Can we have rd_partdesc non null and
rd_partkey null or vice-versa. If not, should we club those into a single
structure like Partition (similar to Relation)?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Wed, Aug 17, 2016 at 11:51 AM, Amit Langote <
langote_amit...@lab.ntt.co.jp> wrote:
> On 2016/08/17 14:33, Ashutosh Bapat wrote:
> >> +relid_is_partition(Oid relid)
> >> +{
> >> + return SearchSysCacheExists1(PARTRELID,
> ObjectIdGetDatum(relid));
|
1779 strcmp(rte->eref->aliasname, objectname) != 0)
1780 appendStringInfo(es->str, " %s",
1781 quote_identifier(rte->eref->aliasname));
Based on this, here is patch to not add schemaname in the prefix for a
var
On Wed, Jan 11, 2012 at 5:25 PM, Chetan Suttraway <
chetan.suttra...@enterprisedb.com> wrote:
>
>
> On Wed, Jan 11, 2012 at 5:13 PM, Ashutosh Bapat <
> ashutosh.ba...@enterprisedb.com> wrote:
>
>> Hi,
>> After running regression, I ran EXPLAIN on on
ide with
the real arr_col member's address.
Am I missing something here?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
array_test.pgc
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
ute for getting an oid
> for a column also. How do we add a column into pg_attribute ?
>
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
On Mon, Mar 24, 2014 at 3:40 PM, Boszormenyi Zoltan wrote:
> 2014-03-24 07:22 keltezéssel, Ashutosh Bapat írta:
>
> Hi,
> I tried using integer array within a structure array in ECPG code. But
> it resulted in some garbage values being printed from the table. Here are
> the
not understand that the "field" is an
array of integers (or for that matter array of anything) and store all the
values in contiguous memory at the given address.
On Thu, Mar 27, 2014 at 11:05 PM, Michael Meskes wrote:
> On Mon, Mar 24, 2014 at 11:52:30AM +0530, Ashutosh Bapat wrote
l) dot Org
> Jabber: michael.meskes at gmail dot com
> VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
>
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
ere we are dumping a pointer to a structure, this code dumps
each member with offset = size of that member, thus again corrupting
memory, if there are more than one rows being saved through pointer.
On Wed, Apr 2, 2014 at 3:10 PM, Michael Meskes wrote:
> On Wed, Apr 02, 2014 at 09:33:15AM +0530
complex
structure.
On Tue, Apr 1, 2014 at 4:34 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> Hi MIchael,
> I tried to fix the offset problem. PFA the patch. It does solve the
> problem of setting wrong offset in ECPGdo() call.
>
> But then there is problem of in
_a_simple() we should dump the variable with arrsize "-1" if
it's part of an outer structure.
The patch attached, includes solutions to both the problems and also a
testcase preproc/pointer_to_struct.pgc. This test is a copy of test
preproc/array_of_struct.pgc with the structure arrays repla
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
> Jabber: michael.meskes at gmail dot com
> VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
>
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
emillion_pgsql.id, onemillion_pgsql.inserted,
> >> onemillion_pgsql.data
> >>Hash Cond: (onemillion_pgsql.id = onemillion.id)
> >>-> Foreign Scan on public.onemillion_pgsql (cost=100.00..38434.00
> >> rows=100 width=30)
> >> Output: onemillion_pgsql.id, onemillion_pgsql.inserted,
> >> onemillion_pgsql.data
> >> Remote SQL: SELECT id, inserted, data FROM public.onemillion
> >>-> Hash (cost=21.85..21.85 rows=100 width=4)
> >> Output: onemillion.id
> >> -> Limit (cost=0.00..20.85 rows=100 width=4)
> >>Output: onemillion.id
> >>-> Seq Scan on public.onemillion (cost=0.00..20834.00
> >> rows=99918 width=4)
> >> Output: onemillion.id
> >> Filter: (onemillion.data > '0.9'::text)
> >> Planning time: 0.215 ms
> >> (14 rows)
> >>
> >> Thanks,
> >>
> >> Best regards,
> >> Etsuro Fujita
> >>
> >>
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
ogue(), use the
address instead of the value at that address
3. The pointer arithmetic should treat such variable as char **, instead of
char *
ECPG regression tests do not show any failures with this patch.
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
d
Let me bring the bug fix again to the surface. Is anybody looking at this
fix?
On Tue, Apr 29, 2014 at 2:25 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> Hi,
> When array of char * is used as target for the FETCH statement returning
> more than one row, it tri
e Debian GNU/Linux, PostgreSQL
>
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
901 - 973 of 973 matches
Mail list logo
