[GENERAL] Postgres Log Message Translations

[Enis Inan]

Hello,

Is there a way I can access the ".po" files containing the English ->
Foreign language translations of postgres' log messages? I only need the
translations from English to Japanese for a project I'm working on.

Thank you!
-Enis

Re: [GENERAL] Results interpretation

[Daniel Verite]

Igor Korot wrote:

> In my case I simply executing:
> 
> SELECT t.table_catalog AS catalog, t.table_schema AS schema,
> t.table_name AS table, u.usename AS owner, c.oid AS table_id FROM
> information_schema.tables t, pg_catalog.pg_class c, pg_catalog.pg_user
> u WHERE t.table_name = c.relname AND c.relowner = usesysid AND
> (t.table_type = 'BASE TABLE' OR t.table_type = 'VIEW' OR t.table_type
> = 'LOCAL TEMPORARY') ORDER BY table_name;
> 
> So I presume the result set will be in a text format, right? For all
> columns?

Yes. Aside from fetching from a binary cursor, I don't think there
is any other way to get binary results from a PQexec() call.
In particular, bytea columns come back encoded as text 
according to the bytea_output setting.


Best regards,
-- 
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite


-- 
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] Results interpretation

[Igor Korot]

Hi, Daniel,

On Sat, Aug 19, 2017 at 12:51 PM, Daniel Verite  wrote:
> Igor Korot wrote:
>
>> If I do PQexec() call, the results will be interpreted as binary or text?
>>
>> I'm trying to get an int field from the query and wonder if I need to do
>> hton() call or not?
>
> In the most general case, you may call
> PQfformat(const PGresult *res, int column_number)
> to know if a column is in text (=0) or binary format (=1)
>
> If you call PQexec("select 1") the result will be in text format.
>
> But if you'd write for instance:
>  PQexec("begin; declare c binary cursor for select 1; fetch all from c;
> end;")
> then the result would be in binary format.
>
> The point is that using PQexec() does not strictly mean that the results
> are in text, as it depends on the query itself. This might be
> significant if there's a requirement that your code has to work
> with any query.

Thank you for an explanation.
It would be nice if the documentation will explicitly state:

"The result set mode (text or binary) depends on the query being executed".

In my case I simply executing:

SELECT t.table_catalog AS catalog, t.table_schema AS schema,
t.table_name AS table, u.usename AS owner, c.oid AS table_id FROM
information_schema.tables t, pg_catalog.pg_class c, pg_catalog.pg_user
u WHERE t.table_name = c.relname AND c.relowner = usesysid AND
(t.table_type = 'BASE TABLE' OR t.table_type = 'VIEW' OR t.table_type
= 'LOCAL TEMPORARY') ORDER BY table_name;

So I presume the result set will be in a text format, right? For all columns?

Thank you.

>
>
> Best regards,
> --
> Daniel Vérité
> PostgreSQL-powered mailer: http://www.manitou-mail.org
> Twitter: @DanielVerite


-- 
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] Results interpretation

[Daniel Verite]

Igor Korot wrote:

> If I do PQexec() call, the results will be interpreted as binary or text?
> 
> I'm trying to get an int field from the query and wonder if I need to do
> hton() call or not?

In the most general case, you may call
PQfformat(const PGresult *res, int column_number)
to know if a column is in text (=0) or binary format (=1)

If you call PQexec("select 1") the result will be in text format.

But if you'd write for instance:
 PQexec("begin; declare c binary cursor for select 1; fetch all from c;
end;")
then the result would be in binary format.

The point is that using PQexec() does not strictly mean that the results
are in text, as it depends on the query itself. This might be
significant if there's a requirement that your code has to work
with any query.


Best regards,
-- 
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite


-- 
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] archive_command fails but works outside of Postgres

[Scott Mead]

> On Aug 19, 2017, at 04:05, twoflower  wrote:
> 
> Alvaro Herrera-9 wrote
> I saw one installation with "gsutil cp" in archive_command recently. It had 
> the CLOUDSDK_PYTHON environment variable set in the archive_command itself. 
> Maybe that's a problem.
> After all, this was the solution:
> archive_command = 'CLOUDSDK_PYTHON=/usr/bin/python gsutil cp 
> /storage/postgresql/9.6/main/pg_xlog/%p gs://my_bucket/'
> as also hinted in https://github.com/GoogleCloudPlatform/gsutil/issues/402 
> 
> I still don't understand why the environments differ (the context of 
> archive_command vs. "su postgres -" and executing it there) but I am happy 
> it's working now. Thank you! 

If postgres is running under systemd, you'll have a wildly different 
environment than if you just su to postgres. 

--Scott


> View this message in context: Re: archive_command fails but works outside of 
> Postgres
> Sent from the PostgreSQL - general mailing list archive at Nabble.com.

Re: [GENERAL] Count column with name 'count' returns multiple rows. Why?

[Peter J. Holzer]

On 2017-08-18 15:57:39 -0500, Justin Pryzby wrote:
> On Fri, Aug 18, 2017 at 10:47:37PM +0200, Peter J. Holzer wrote:
> > On 2017-08-18 06:37:15 -0500, Justin Pryzby wrote:
> > > On Fri, Aug 18, 2017 at 01:01:45PM +0200, Rob Audenaerde wrote:
> > > > Can anyone please explain this behaviour?
> > > 
> > > https://www.postgresql.org/docs/9.6/static/sql-expressions.html#SQL-EXPRESSIONS-FUNCTION-CALLS
> > > https://www.postgresql.org/docs/9.6/static/rowtypes.html#ROWTYPES-USAGE
> > 
> > Maybe I overlooked it, but I don't see anything in those pages which
> > explains why «count» is parsed as a column name in the first example and
> > as a function name in the second.
> > 
> > Nor do I see what «count(base.*)» is supposed to mean. It seems to be
> > completely equivalent to just writing «count», but the part in
> > parentheses is not ignored: It has to be either the table name or the
> > table name followed by «.*». Everything else I tried either led to a
> > syntax error or to «count» being recognized as a function. So apparently
> > columnname open-parenthesis tablename closed-parenthesis is a specific
> > syntactic construct, but I can't find it documented anywhere.
> 
> | Another special syntactical behavior associated with composite values is 
> that
> |we can use functional notation for extracting a field of a composite value. 
> The
> |simple way to explain this is that the notations field(table) and table.field
> |are interchangeable. For example, these queries are equivalent:

Thanks. I see it now.

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 


signature.asc
Description: Digital signature

Re: [GENERAL] archive_command fails but works outside of Postgres

[twoflower]

Alvaro Herrera-9 wrote
> I saw one installation with "gsutil cp" in archive_command recently. 
> Ithad the CLOUDSDK_PYTHON environment variable set in the
> archive_commanditself.  Maybe that's a problem.

After all, this was the solution:
archive_command = 'CLOUDSDK_PYTHON=/usr/bin/python gsutil cp
/storage/postgresql/9.6/main/pg_xlog/%p gs://my_bucket/'
as also hinted in  https://github.com/GoogleCloudPlatform/gsutil/issues/402
  

I still don't understand why the environments differ (the context of
archive_command vs. "su postgres -" and executing it there) but I am happy
it's working now.Thank you!



--
View this message in context: 
http://www.postgresql-archive.org/archive-command-fails-but-works-outside-of-Postgres-tp5979040p5979093.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.