string not marked for translation
Here is a fix for a string that is not marked for translation.
I created two full strings instead of the "trick" used to make it shorter.
It's usually not a good idea to be too clever when dealing with
translations.
--
/Dennis
Attachments:
pg_command_user_translate_fix.patchtext/plain; charset=US-ASCII; name=pg_command_user_translate_fix.patchDownload+6-2
Dennis Bjᅵrklund writes:
Here is a fix for a string that is not marked for translation.
Done.
--
Peter Eisentraut peter_e@gmx.net
Hi
When a table was created without oids, we have not a valid oid returned
from backend.
How would be a patch to return last tid?
Command Status string seem to be a good place to do it, after tuple count
modified or inserted for last insert statement.
Would this patch break something?
What possible code I must modify to accomplish this?
Thanks
Arturo
"Arturo =?ISO-8859-15?Q?Jos=E8?= Montes Sinning" <mitosys@colomsat.net.co> writes:
How would be a patch to return last tid?
TID is completely unstable; I would not recommend any client use it to
identify rows, and I would certainly not hold still for a protocol
modification to encourage such usage.
regards, tom lane
Hi
Tom Lane wrote:
"Arturo =?ISO-8859-15?Q?Jos=E8?= Montes Sinning" <mitosys@colomsat.net.co> writes:
How would be a patch to return last tid?
TID is completely unstable; I would not recommend any client use it to
identify rows, and I would certainly not hold still for a protocol
modification to encourage such usage.
OK, I understand the point, however i am experimenting a serios
performance penalty using rowid to identify rows, because the
oid is a serial and not implement a index method on it.
I am talking about select <select-list> from <table> where oid=<oid>
When the table has thousands records this query is executed by Postgres
as sequential scan. The other problems come from insert. We are paying
an extra cost when insert a row because oid sequence computation.
Then, we decide to use ctid pseudo column, however this value is not
returned by libpq, only the oid, still when the table was created without
oids. I don't want break code, of course, however when the table has not
oid the oid returned is 0 in PQoidvalue and PQcmdStatus (I guess PQoidvalue
fill this value from PQcmdStatus), and then my proposol is send the tid
in a packet integer form instead of oid (0 value). For example, the integer
would be (blocknum<<8)|(recordno). Where blocknum is the number of block
where tuple reside and recordno is the index inside the block.
Thanks
Arturo
Show quoted text
regards, tom lane
"Arturo =?ISO-8859-1?Q?Jos=E8?= Montes Sinning" <mitosys@colomsat.net.co> writes:
I am talking about select <select-list> from <table> where oid=<oid>
When the table has thousands records this query is executed by Postgres
as sequential scan.
Create an index on OID, if you want to use it to find rows quickly...
The other problems come from insert. We are paying
an extra cost when insert a row because oid sequence computation.
I've never seen any evidence that generating an OID is a significant
part of the time needed to do an INSERT (and yes, I've done profiling
of such things).
regards, tom lane