Обсуждение: do not obtain all columns from DBD::Pg

Okay... thanks for the replies on the 'cannot remove column' topic. That
answer indeed quite obvious..

some other newbie-related issue:

If I select all columns from a pgsql-table from a Perl-Script (by using
DBD::pg by doing something like:

#select all column names:
my $results = $dbh->selectall_arrayref("SELECT column_name FROM
information_schema.columns WHERE table_name ='simulations_ltbl'")
        or warn "something goes wrong here";

# print all column names:
for my $row (@$results) {
    print "@$row\n";
}

then I don't get the complete set of columns compared to when I execute
the SQL directly in PostgreSQL. Especially I miss 2 column names in
Perl, which have types 'timestamp without time zone' and 'character
varying(255)', which are shown without problem when using the psql client.

Sounds like some DBD-related issue in displaying all supported column
values, but on the DBD::pg site on CPAN, both datatypes are supported.
Something else knows what's wrong with this?

any help is appreciated,

Bram

Bram Kuijper <a.l.w.kuijper@rug.nl> writes:
> If I select all columns from a pgsql-table from a Perl-Script (by using
> DBD::pg by doing something like:
> ...
> then I don't get the complete set of columns compared to when I execute
> the SQL directly in PostgreSQL. Especially I miss 2 column names in
> Perl, which have types 'timestamp without time zone' and 'character
> varying(255)', which are shown without problem when using the psql client.

> Sounds like some DBD-related issue in displaying all supported column
> values, but on the DBD::pg site on CPAN, both datatypes are supported.

I doubt it: the data you selected from information_schema.columns is
quite independent of the column types, so even if there were such a
problem in DBD::pg it could hardly manifest in this way.

What I'm wondering about is if you are connecting to the same database
in both the DBD::pg test program and the manual psql try.  Another
possibility is multiple tables of the same name in different schemas,
perhaps compounded by different ownerships --- I think the
information_schema hides info about tables you don't have any access
privileges for.  Is the test program connecting as the same database
user you were using manually?

            regards, tom lane