Re: [GENERAL] PLPGSQL returning number of rows

[David G. Johnston]

On Thu, Nov 10, 2016 at 5:44 PM, Patrick B  wrote:

> Hi guys,
>
> I'm writing a simple Plpgsql function to delete some data from different
> tables.
>
> The function starts with a select, and then 2 deletes after that.
>
> How can I return the number of rows that each delete performed?
>
>
​The pl/pgsql chapter named: "Basic Statements - Obtaining the Result
Status" sounds like a good place to look...

Here's a link:

https://www.postgresql.org/docs/9.6/static/plpgsql-statements.html#PLPGSQL-STATEMENTS-DIAGNOSTICS
​

​David J.

[GENERAL] PLPGSQL returning number of rows

[Patrick B]

Hi guys,

I'm writing a simple Plpgsql function to delete some data from different
tables.

The function starts with a select, and then 2 deletes after that.

How can I return the number of rows that each delete performed?


CREATE or REPLACE FUNCTION delete_ids_clientid(account_id integer)

RETURNS integer AS $$


declare

row record;

account_id integer;


BEGIN


FOR row IN EXECUTE '

SELECT

t1.id

FROM

public.table2 t2

JOIN

public.table1 t1 ON t2.id = t1.id

WHERE

t2.account_id = ' || account_id || ''

LOOP


DELETE FROM public.table1 WHERE id IN

(

SELECT

id

FROM

public.table1 t1

WHERE

t1.id = row.id

);


DELETE FROM public.table2 WHERE billable_id IN

(

SELECT

billable_id

FROM

public.table2 t1

WHERE

t1.id = row.id

);



END LOOP;

END


$$ language 'plpgsql';



Cheers

Re: [GENERAL] Gin indexes on intarray is fast when value in array does not exists, and slow, when value exists

[Tom Lane]

Jeff Janes  writes:
> On Thu, Nov 10, 2016 at 7:11 AM, Tom Lane  wrote:
>> If you are using that contrib module, and it's capturing this operator
>> reference, that would probably explain the bad estimate.  You could
>> drop the extension if you're not depending on its other features, or you
>> could explicitly qualify the operator name ("operator(pg_catalog.@>)"),
>> or you could upgrade to 9.6 (don't forget to do ALTER EXTENSION ... UPDATE
>> afterwards).

> Isn't the operator determined at index build time?  If he doesn't want to
> update to 9.6, I think he would need to rebuild the index, removing
> the "gin__int_ops" specification.

The operator in the query isn't.  But yes, if he's using an index that's
built on the extension's opclass, he'd need to rebuild that too in order
to still use the index with the core @> operator.

regards, tom lane


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Gin indexes on intarray is fast when value in array does not exists, and slow, when value exists

[Jeff Janes]

On Thu, Nov 10, 2016 at 7:11 AM, Tom Lane  wrote:

> otar shavadze  writes:
> >> Hmmm ... actually, I wonder if maybe '@>' here is the contrib/intarray
> >> operator not the core operator?  The intarray operator didn't get
> plugged
> >> into any real estimation logic until 9.6.
>
> > So, you mean that better would be go to version 9.6 ?
>
> If you are using that contrib module, and it's capturing this operator
> reference, that would probably explain the bad estimate.  You could
> drop the extension if you're not depending on its other features, or you
> could explicitly qualify the operator name ("operator(pg_catalog.@>)"),
> or you could upgrade to 9.6 (don't forget to do ALTER EXTENSION ... UPDATE
> afterwards).
>

Isn't the operator determined at index build time?  If he doesn't want to
update to 9.6, I think he would need to rebuild the index, removing
the "gin__int_ops" specification.

Cheers,

Jeff

Re: [GENERAL] How to hint 2 coulms IS NOT DISTINCT FROM each other

[Kim Rose Carlsen]

> Hang on -- upthread the context was inner join, and the gripe was join

> fast with '=', slow with INDF.  When he said the nulls were
> 'generated', I didn't follow that they were part of the original
> query.  If the nulls are generated along with the query, sure, an
> index won't help.
>
> I maintain my earlier point; with respect to the original query, to
> get from performance of INDF to =, you have three options:
> a) expr index the nulls  (assuming they are physically stored)
> b) convert to ((a = b) or a is null and b is null) which can help with
> a bitmap or plan
> c) covert to union all equivalent of "b"
>
> merlin

a) and b) would be workaround that would run an order of magnitude slower. The 
query
starts with a full table scan of a large table. If the planner had started 
elsewhere it could
have reduced the result to 1-2 rows from the start. It won't choose this plan 
without the help
from =.

c) could be a acceptable workaround, but it would clutter up if you would want 
more
than one column to be IS NOT DISTINCT FROM. You end up with 2^n unions to 
simulate
IS NOT DISTINCT FROM.

Without knowing the work required, I will still argue that having IS NOT 
DISTINCT FROM
use the same transitive rules as equality,  would be a better approach.

With fear of talking about things I know little(nothing) of, I think the 
description of EquivalenceClasses
in postgres/src/backend/optimizer/README, should be extended to also include 
EquivalenceClasses
of IS NOT DISTINCT FROM.

Re: [GENERAL] Gin indexes on intarray is fast when value in array does not exists, and slow, when value exists

[Tom Lane]

otar shavadze  writes:
>> Hmmm ... actually, I wonder if maybe '@>' here is the contrib/intarray
>> operator not the core operator?  The intarray operator didn't get plugged
>> into any real estimation logic until 9.6.

> So, you mean that better would be go to version 9.6 ?

If you are using that contrib module, and it's capturing this operator
reference, that would probably explain the bad estimate.  You could
drop the extension if you're not depending on its other features, or you
could explicitly qualify the operator name ("operator(pg_catalog.@>)"),
or you could upgrade to 9.6 (don't forget to do ALTER EXTENSION ... UPDATE
afterwards).

regards, tom lane


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Row level security performance joining large tables

[Stephen Frost]

David,

* David R. Pike (david.p...@trustedconcepts.com) wrote:
> From what I can understand the RLS implementation strives to execute policy 
> checks before user provided predicate checks so as to avoid leaking protected 
> data.  Is there any way to make the join look "safe" to the optimizer to 
> avoid full table scans?  Isn't this a common scenario?

You can use a security barrier view which is owned by the same user that
the tables underneath are owned by, that will bypass RLS on the tables
themselves and therefore you'll need to implement the appropriate quals
in the security barrier view.

As Tom mentions, we're working to improve RLS optimization as well.  As
is pretty common with various features, the initial implementation
provides the functionality but perhaps isn't as performant as one might
like, and then we iterate and improve it in the subsequent releases.

Thanks!

Stephen


signature.asc
Description: Digital signature

Re: [GENERAL] Postgresql 94 from PostgreSQL RPM Repository (with Yum)

[Adrian Klaver]

On 11/10/2016 04:56 AM, Steve Clark wrote:
> Hi
> 
> I installed the following package:
> postgresql94-server-9.4.9-1PGDG.rhel6.x86_64
> postgresql94-plperl-9.4.9-1PGDG.rhel6.x86_64
> postgresql94-plpython-9.4.9-1PGDG.rhel6.x86_64
> postgresql94-contrib-9.4.9-1PGDG.rhel6.x86_64
> postgresql94-devel-9.4.9-1PGDG.rhel6.x86_64
> postgresql94-libs-9.4.9-1PGDG.rhel6.x86_64
> postgresql94-9.4.9-1PGDG.rhel6.x86_64
> 
> Then tried to build pmacct and the configure complained it couldn't find
> the libpq library. I looked for
> a package-config file for the above but couldn't find one.
> 
> What am I missing?

I just ran the configure on a source installed version of Postgres and it 
worked.

What it was looking for:

checking whether to enable PostgreSQL support... yes
checking for PGSQL... no
checking default locations for libpq... found in /usr/local/pgsql/lib
checking default locations for libpq-fe.h... found in /usr/local/pgsql/include


And from the configure file:

{ $as_echo "$as_me:${as_lineno-$LINENO}: checking default locations for 
libpq-fe.h" >&5
$as_echo_n "checking default locations for libpq-fe.h... " >&6; }
if test -r /usr/include/libpq-fe.h; then
PGSQL_CFLAGS="-I/usr/include"
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: found in 
/usr/include" >&5
$as_echo "found in /usr/include" >&6; }
elif test -r /usr/include/postgresql/libpq-fe.h; then
PGSQL_CFLAGS="-I/usr/include/postgresql"
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: found in 
/usr/include/postgresql" >&5
$as_echo "found in /usr/include/postgresql" >&6; }
elif test -r /usr/local/include/libpq-fe.h; then
PGSQL_CFLAGS="-I/usr/local/include"
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: found in 
/usr/local/include" >&5
$as_echo "found in /usr/local/include" >&6; }
elif test -r /usr/local/pgsql/include/libpq-fe.h; then
PGSQL_CFLAGS="-I/usr/local/pgsql/include"
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: found in 
/usr/local/pgsql/include" >&5
$as_echo "found in /usr/local/pgsql/include" >&6; }
else
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: not found" >&5
$as_echo "not found" >&6; }
_save_CFLAGS="$CFLAGS"
CFLAGS="$CFLAGS $PGSQL_CFLAGS"
ac_fn_c_check_header_mongrel "$LINENO" "libpq-fe.h" 
"ac_cv_header_libpq_fe_h" "$ac_includes_default"
if test "x$ac_cv_header_libpq_fe_h" = xyes; then :


So it is looking in the default source install locations. The RPMs I believe
install in different locations. Running configure --help shows environment 
variables 
that can be set to change the configure search behavior.


> 
> Thanks,
> Steve
> 
> 
> 
> 


-- 
Adrian Klaver
adrian.kla...@aklaver.com


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Postgresql 94 from PostgreSQL RPM Repository (with Yum)

[Devrim Gündüz]

Hi Steve,

On Thu, 2016-11-10 at 07:56 -0500, Steve Clark wrote:
> 
> I installed the following package:
> postgresql94-server-9.4.9-1PGDG.rhel6.x86_64
> postgresql94-plperl-9.4.9-1PGDG.rhel6.x86_64
> postgresql94-plpython-9.4.9-1PGDG.rhel6.x86_64
> postgresql94-contrib-9.4.9-1PGDG.rhel6.x86_64
> postgresql94-devel-9.4.9-1PGDG.rhel6.x86_64
> postgresql94-libs-9.4.9-1PGDG.rhel6.x86_64
> postgresql94-9.4.9-1PGDG.rhel6.x86_64
> 
> Then tried to build pmacct and the configure complained it couldn't find the
> libpq library. I looked for
> a package-config file for the above but couldn't find one.
> 
> What am I missing?

Can you please run

export PKG_CONFIG_PATH=/usr/pgsql-9.4/lib/pkgconfig/

and then run configure script again?

Regards,
-- 
Devrim GÜNDÜZ
EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Twitter: @DevrimGunduz , @DevrimGunduzTR


signature.asc
Description: This is a digitally signed message part

Re: [GENERAL] Syncing Data of data type BLOB into Postgres- Bytea

[Adrian Klaver]

On 11/09/2016 11:35 PM, Cynthia Hombakazi Ngejane wrote:



Hello,

I have two databases SQLlite and Postgres,  SQLite is my local database
in it I am saving fingerprint templates that get capture onsite (i.e
offline) and my column is of type BLOB. Now I want to sync these
templates into Postgres (to the server), so I created a column of type
bytea but Postgres is refusing to take BLOB it says there was a syntax
error. I am using Qt c++ 5.7  application  to do the syncing.


What version of Postgres?

What is the syntax error?

What is the code you are using to insert/update the data into Postgres?



Please Help...

CH Ngejane





--
Adrian Klaver
adrian.kla...@aklaver.com


--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Import data from MS SQL Server 2014 to Postgresql 9.6 using dbi-link and fdw (error: utf-8/uft-16)

[rob stone]

On Thu, 2016-11-10 at 05:34 -0500, Juliano wrote:
> Hi,
>  
> I'm trying to import some data from a MS SQL Server 2014 sequential
> database to Postgresql using dbi-link.
>  
> Postgresql 9.6 encoding is utf-8 and does not support utf-16 but, I
> need to transfer this data to postgres.
>  
> I also tried to use tds_fdw version 1.0.8 and the same problem
> occurs.
>  
> ERROR: DB-Library error: DB #: 100, DB Msg: TDS version downgraded to
> 7.1!, OS #: 0, OS Msg: Success, Level: 1
>  
> ** Error **
>  
> ERROR: DB-Library error: DB #: 100, DB Msg: TDS version downgraded to
> 7.1!, OS #: 0, OS Msg: Success, Level: 1
> SQL state: HV00L
>  
> Please help me.
> 


The error code HV00L means "unable to create execution".

This appears to have been fixed. See:-

https://github.com/tds-fdw/tds_fdw/issues/83


However, I don't follow "how" the UTF-16 data is being transformed to
UTF-8. I know that I'm thick (at times). If the SQL Server data is in
Simplified Chinese (say), how do you convert it?

Postgres handles some multi-byte codings:-

WIN932 --> SJIS
WIN936 --> GBK
WIN949 --> UHC
WIN950 --> BIG5

So you can run createdb specifying one of those encodings, lc_collate,
etc.


HTH,

Rob 


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Import data from MS SQL Server 2014 to Postgresql 9.6 using dbi-link and fdw (error: utf-8/uft-16)

[Tim Clarke]

I'd recommend Talend, they have an open source edition that we use. Very
powerful and reliable.


Tim Clarke

On 10/11/16 12:49, JingYuan Chen wrote:
>
> I think that ETL utilities will be the right choice. Try Pentaho's
> Data Integration tool. It is Java base.
>
>
> On Nov 10, 2016 6:45 PM, "Raymond O'Donnell"  > wrote:
>
> On 10/11/16 10:34, Juliano wrote:
>
> Hi,
>
>
>
> I'm trying to import some data from a MS SQL Server 2014
> sequential
> database to Postgresql using dbi-link.
>
>
> Have you tried the foreign data wrapper for MS SQL Server? It's here:
>
> 
> https://wiki.postgresql.org/wiki/Foreign_data_wrappers#Specific_SQL_Database_Wrappers
> 
> 
>
> Not something I've done, but it may be worth a try.
>
> Ray.
>
>
>
> -- 
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org
> )
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
> 
>



smime.p7s
Description: S/MIME Cryptographic Signature

[GENERAL] Postgresql 94 from PostgreSQL RPM Repository (with Yum)

[Steve Clark]

Hi

I installed the following package:
postgresql94-server-9.4.9-1PGDG.rhel6.x86_64
postgresql94-plperl-9.4.9-1PGDG.rhel6.x86_64
postgresql94-plpython-9.4.9-1PGDG.rhel6.x86_64
postgresql94-contrib-9.4.9-1PGDG.rhel6.x86_64
postgresql94-devel-9.4.9-1PGDG.rhel6.x86_64
postgresql94-libs-9.4.9-1PGDG.rhel6.x86_64
postgresql94-9.4.9-1PGDG.rhel6.x86_64

Then tried to build pmacct and the configure complained it couldn't find the 
libpq library. I looked for
a package-config file for the above but couldn't find one.

What am I missing?

Thanks,
Steve




--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Import data from MS SQL Server 2014 to Postgresql 9.6 using dbi-link and fdw (error: utf-8/uft-16)

[JingYuan Chen]

I think that ETL utilities will be the right choice. Try Pentaho's Data
Integration tool. It is Java base.

On Nov 10, 2016 6:45 PM, "Raymond O'Donnell"  wrote:

> On 10/11/16 10:34, Juliano wrote:
>
>> Hi,
>>
>>
>>
>> I'm trying to import some data from a MS SQL Server 2014 sequential
>> database to Postgresql using dbi-link.
>>
>
> Have you tried the foreign data wrapper for MS SQL Server? It's here:
>
> https://wiki.postgresql.org/wiki/Foreign_data_wrappers#Speci
> fic_SQL_Database_Wrappers
>
> Not something I've done, but it may be worth a try.
>
> Ray.
>
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

Re: [GENERAL] Gin indexes on intarray is fast when value in array does not exists, and slow, when value exists

[otar shavadze]

@Jeff


> most_common_elems.  Is it empty, or is it not empty?  If not empty, does
> it contain the specific values you used in your queries?


No, most_common_elems is not empty. it contain the specific values I used
in queries.



@Tom

>
> Hmmm ... actually, I wonder if maybe '@>' here is the contrib/intarray
> operator not the core operator?  The intarray operator didn't get plugged
> into any real estimation logic until 9.6.



So, you mean that better would be go to version 9.6 ?

On Wed, Nov 9, 2016 at 8:35 AM, Tom Lane  wrote:

> I wrote:
> > Seems like your problem here is that the planner has no idea about the
> > selectivity of this condition --- if it did, I think it would have
> > made the right choice, because it would have made a much higher estimate
> > for the cost of the indexscan.
>
> > AFAICT, Postgres 9.5 does make a reasonably correct guess when given
> > up-to-date stats.  I speculate that you need to ANALYZE this table.
>
> Hmmm ... actually, I wonder if maybe '@>' here is the contrib/intarray
> operator not the core operator?  The intarray operator didn't get plugged
> into any real estimation logic until 9.6.
>
> regards, tom lane
>

Re: [GENERAL] Import data from MS SQL Server 2014 to Postgresql 9.6 using dbi-link and fdw (error: utf-8/uft-16)

[Raymond O'Donnell]

On 10/11/16 10:34, Juliano wrote:

Hi,



I'm trying to import some data from a MS SQL Server 2014 sequential
database to Postgresql using dbi-link.


Have you tried the foreign data wrapper for MS SQL Server? It's here:

https://wiki.postgresql.org/wiki/Foreign_data_wrappers#Specific_SQL_Database_Wrappers

Not something I've done, but it may be worth a try.

Ray.



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

[GENERAL] Import data from MS SQL Server 2014 to Postgresql 9.6 using dbi-link and fdw (error: utf-8/uft-16)

[Juliano]

Hi,





I'm trying to import some data from a MS SQL Server 2014 sequential database to 
Postgresql using dbi-link.





Postgresql 9.6 encoding is utf-8 and does not support utf-16 but, I need to 
transfer this data to postgres.





I also tried to use tds_fdw version 1.0.8 and the same problem occurs.





ERROR: DB-Library error: DB #: 100, DB Msg: TDS version downgraded to 7.1!, OS 
#: 0, OS Msg: Success, Level: 1





** Error **





ERROR: DB-Library error: DB #: 100, DB Msg: TDS version downgraded to 7.1!, OS 
#: 0, OS Msg: Success, Level: 1


SQL state: HV00L





Please help me.

Re: [GENERAL] initdb createuser commands

[Samuel Williams]

> Really? So naming them pg_initdb and pg_createdb would help to clarify their 
> use?

Yes.

> Perhaps you missed: https://www.postgresql.org/docs/9.6/static/app-pg-ctl.html

I meant a man page that details the ENTIRE Postgres command line tools.

> Command line aliases and other stuff

I've been using Linux since kernels were 1.x - come on, I know what an
alias is. You've missed the forest for the trees.

> I think the OP's point is that having a hodgepodge of (on their face) 
> unrelated commands smells kinda unorganized at best and unprofessional at 
> worst.  Wether or not he's right is up to the reader.  For me, I agree with 
> his sentiment.

Yes exactly.

> The solution he's suggesting is to bring all of these commands under one 
> umbrella either by bundling them in an administrative utility or by giving 
> them a prefix that shows they're related to "the PostgreSQL database."

Correct.

> He's getting a lot of pushback that really feels it's coming from the wrong 
> direction.  "Just learn it."  "It's always been this way."  "No one agrees 
> with you."  These arguments are unconvincing.  That said, there's nothing 
> wrong with just saying, "we're not going to change it because we don't want 
> to."

I'm okay with any of those options. But I just wanted to raise this
from the POV of a new user. However, I'm not a "beginner" as such.

> There is the issue that by introducing new commands that are better 
> organised, the new user will get introduced to more commands instead of fewer 
> - when they run into a problem or if they bought the book, the commands 
> they'll encounter will be the "old" commands.

Can be solved with time and backwards aliases/deprecated commands
which are maintained for a few more releases.

> There's also the learning curve of having a single wrapper-command that can 
> do anything pg-related. The purpose of a command named pg_createuser is 
> obvious, the purpose of a command named pg or pga is not so obvious.

I agree this is a valid POV. But I think the opposite is also true. I
have command line tools that when run with no arguments give a very
nice succinct description of the tool and sub-commands.

> I do think however that having the pg-commands prefixed with pg_ is actually 
> helpful to both new and experienced users. One reason is that it limits the 
> number of commands matched for command completion after typeing pg_ (which is 
> only 3 characters to type). ISTR some argument against using underscores 
> because they would be hard to type, but I can't understand why.

TAB completion is a really good point and a big one. It helps you
discover related commands. It's good for all users. W.r.t. underscores
- to type _ one must press shift... I have to stretch my pinky :D It's
uncomfortable and a bit slower than just.. say, any other letter or a
dash.

> That said, renaming the commands provides a rather minor benefit at best. 
> Having this much fuss about it is out of proportion IMHO. I remember learning 
> those commands (when pg 7.4.7 was a big deal) and it certainly did not cost 
> me the majority of time that I needed to learn to use pg, and once I did 
> learn them I knew where to find at least the documentation.

I'm not the one really fussing, I'm just answering people's objections
where I think they are incorrect or misunderstanding my original
statements. I think that's polite to do so - I made an investment of
time to bring attention to what I feel is an issue and I'm prepared to
invest the time to see it through.

I think that the benefit is probably more than minor, if the command
line interface is crappy people will struggle with the tool as you've
mentioned. But if it's good, people will love it. What kind of feeling
do you want to invoke in users of Postgresql?

> It allows you to handle multiple instances  of Postgres easily

This is awesome, but I feel like it would be better if this was
bundled as part of Postgres so it would work on all platforms
consistently, not just Debian. The fact they are doing it shows that
there is a need for it.

> In this list, the convention is to post replies at the end (with some rare 
> exceptions),
or interspersed when appropriate, and to omit parts no longer relevant.

My apologies, Gmail is a heap of crap and hides everything by default. Bleh :)

> The community often does a horrible job of viewing things through the eyes of 
> a new user. This is why mysql became so popular for a while. Comments like 
> "just learn it" are unproductive and push new users away.

I'd agree with this and I agree that this is the feeling I'm getting
from the replies here.

Thanks everyone for your thoughtful replies.


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Linux equivalent library for "postgres.lib" from Windows

[David Guyot]

If you are looking for the name of the package providing the postgres
library, it will probably change over the distros; under Debian, you're
probably looking for libpq5 for the library itself, but I don't know the
name of the package containing debugging symbols for this one.

Depending on your development language, the corresponding package name can be 
different, and there can be a package with debugging symbols.

Regards.

Le mardi 08 novembre 2016 à 05:01 +, Gadamsetty, Kiran a écrit :
> We are depending on postgres.lib while creating a postgre extension for 
> windows. 
> We need to know the equivalent library in Linux to build the same in Linux to 
> get the symbols resolve correctly.
> 
> Any help is appreciated.
> 
> -Kiran G 
-- 
David Guyot
Administrateur système, réseau et télécom / Sysadmin
Europe Camions Interactive / Stockway
Moulin Collot
F-88500 Ambacourt
03 29 30 47 85


signature.asc
Description: This is a digitally signed message part