Re: v 1.16.1 incorrectly displays the properties of a FDW table

For the benefit of the list/archives, Dinesh and I discussed this issue
earlier and he's going to investigate why we see differences with the same
binary on Windows 7 vs. Windows XP which is really very unusual.

On Mon, Aug 5, 2013 at 10:57 AM, Dinesh Kumar <dinesh(dot)kumar(at)enterprisedb(dot)com
> wrote:

> Hi Dave,
>
> We are able to re-produce the same case in windows xp, but not in windows
> 7. Below is the output for the table which has been created in PG 9.2.
>
> XP (pgAdmin 1.16.1)
> -----
> CREATE FOREIGN TABLE person
> (name text ,
> spouse text )
> SERVER file_fdw_serv
> OPTIONS (format 'text,filename=/tmp/test.txt,', elimiter '', , '',
> ull '\\\\N"');
> ALTER FOREIGN TABLE person
> OWNER TO postgres;
>
>
> Win 7 (pgAdmin 1.16.1)
> --------
> CREATE FOREIGN TABLE person
> (name text ,
> spouse text )
> SERVER file_fdw_serv
> OPTIONS (format 'text', filename '/tmp/test.txt', delimiter ',', null
> 'N');
> ALTER FOREIGN TABLE person
> OWNER TO postgres;
>
>
> Actual Definitions From PG (9.2)
> ------------------------------------
> postgres=# \d person
> Foreign table "public.person"
>
> Column | Type | Modifiers | FDW Options
> --------+------+-----------+-------------
> name | text | |
> spouse | text | |
> Server: file_fdw_serv
> FDW Options: (format 'text', filename '/tmp/test.txt', delimiter ',',
> "null" E'\\\\N')
>
>
> I believe, the code in "pgForeignTable::iSetOptions(const wxString
> &tmpoptions)" is behaving differently on windows xp as well in 7.
>
> I have installed the PG 9.3 beta version which comes with pgAdmin 1.18.x
> in Win XP. In that version also, win xp is behaving like reported. Hence, i
> would like to setup the build in XP and will try to fix the problem.
>
> Kindly let me know your inputs.
>
> Thanks in advance.
>
> Dinesh
>
> --
> *Dinesh Kumar*
> Software Engineer
>
> Ph: +918087463317
> Skype ID: dinesh.kumar432
> www.enterprisedb.co <http://www.enterprisedb.com/>m<http://www.enterprisedb.com/>
> *
> Follow us on Twitter*
> @EnterpriseDB
>
> Visit EnterpriseDB for tutorials, webinars, whitepapers<http://www.enterprisedb.com/resources-community> and
> more <http://www.enterprisedb.com/resources-community>
>
>
> On Mon, Aug 5, 2013 at 11:49 AM, Dinesh Kumar <
> dinesh(dot)kumar(at)enterprisedb(dot)com> wrote:
>
>> Sure Dave, will work on this issue.
>>
>> Dinesh
>>
>> --
>> *Dinesh Kumar*
>> Software Engineer
>>
>> Ph: +918087463317
>> Skype ID: dinesh.kumar432
>> www.enterprisedb.co <http://www.enterprisedb.com/>m<http://www.enterprisedb.com/>
>> *
>> Follow us on Twitter*
>> @EnterpriseDB
>>
>> Visit EnterpriseDB for tutorials, webinars, whitepapers<http://www.enterprisedb.com/resources-community> and
>> more <http://www.enterprisedb.com/resources-community>
>>
>>
>> On Fri, Aug 2, 2013 at 11:00 PM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
>>
>>> Dinesh, can you look at this please? Thanks.
>>>
>>> On Thu, Aug 1, 2013 at 11:40 PM, Bill MacArthur <webmaster(at)dhs-club(dot)com>
>>> wrote:
>>> > Hello,
>>> >
>>> > I am guessing that somebody has already reported this, but in case
>>> not, here
>>> > goes. I am using version 1.16.1 on windows XP against a Postgres
>>> version
>>> > 9.2.4 server. The wrapper options for a foreign data wrappers table get
>>> > really goobered up inside of pgadmin.
>>> > I have a foreign table that is defined by \d as:
>>> >
>>> > network=# \d test.grpmgt
>>> > Foreign table "test.grpmgt"
>>> > Column | Type | Modifiers | FDW Options
>>> > --------+---------+-----------+-------------
>>> > id | integer | |
>>> > uptime | integer | |
>>> > paid | boolean | |
>>> > Server: file_server
>>> > FDW Options: (format 'text', filename '/tmp/grpmgt', delimiter ',',
>>> "null"
>>> > E'\\\\N')
>>> >
>>> >
>>> > However, the same object is reported in pgadmin as:
>>> >
>>> > CREATE FOREIGN TABLE work.grpmgt
>>> > (id integer ,
>>> > upline integer ,
>>> > paid boolean )
>>> > SERVER file_server
>>> > OPTIONS (format 'text,filename=/tmp/grpmgt,', elimiter '', , '', ull
>>> > '\\\\N"');
>>> >
>>> >
>>> > As you can well imagine, that SQL statement cannot recreate that
>>> table. It
>>> > breaks down in the OPTIONS.
>>> >
>>> > Pgadmin is a wonderful tool and this aberration is of minimal
>>> consequence to
>>> > me, but I figure that the least I could do to help make it better
>>> would be
>>> > to report this.
>>> >
>>> > Thank you much.
>>> > Bill MacArthur
>>> >
>>> >
>>> > --
>>> > Sent via pgadmin-support mailing list (pgadmin-support(at)postgresql(dot)org)
>>> > To make changes to your subscription:
>>> > http://www.postgresql.org/mailpref/pgadmin-support
>>>
>>>
>>>
>>> --
>>> Dave Page
>>> Blog: http://pgsnake.blogspot.com
>>> Twitter: @pgsnake
>>>
>>> EnterpriseDB UK: http://www.enterprisedb.com
>>> The Enterprise PostgreSQL Company
>>>
>>
>>
>

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company