Thanks!
That's what I'm searching for.
Janek
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On 12/31/2013 04:03 PM, Joseph Kregloh wrote:
On Tue, Dec 31, 2013 at 5:08 PM, Adrian Klaver mailto:adrian.kla...@gmail.com>> wrote:
On 12/31/2013 01:31 PM, Joseph Kregloh wrote:
ERROR: relation "sys_errors" does not exist
LINE 1: SELECT * FROM sys_err
On Tue, Dec 31, 2013 at 5:08 PM, Adrian Klaver wrote:
> On 12/31/2013 01:31 PM, Joseph Kregloh wrote:
>
>>
>> ERROR: relation "sys_errors" does not exist
>> LINE 1: SELECT * FROM sys_errors ORDER BY created_ts DESC LIMIT
>> 100;
>> ^
>>
On 12/31/2013 03:06 PM, John R Pierce wrote:
On 12/31/2013 2:34 PM, Adrian Klaver wrote:
point is just x,y, it doesn't understand the spherical lat/long math
(unless you install PostGIS and use its Geometry types which are fully
aware of spherical coords), that said, Latitude is generally used a
On 12/31/2013 2:34 PM, Adrian Klaver wrote:
point is just x,y, it doesn't understand the spherical lat/long math
(unless you install PostGIS and use its Geometry types which are fully
aware of spherical coords), that said, Latitude is generally used as X
(left/right, aka east/west), while Longitu
Perfect. That answers it. Thanks for providing that link.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Format-of-Pioint-datatype-lat-long-or-long-lat-tp5784939p5784960.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
--
Sent via pgsql-
On 12/31/2013 02:16 PM, peterlen wrote:
Adrian - Thanks for the reply. The example was from
http://www.postgresql.org/docs/9.1/static/tutorial-populate.html with the
example of:
INSERT INTO cities VALUES ('San Francisco', '(-194.0, 53.0)');
That is not a valid coordinate but it is clear that t
Hello
this transformation is implemented inside parser - so you can not use a
parameters there. You can use a dynamic SQL trick
http://postgres.cz/wiki/PostgreSQL_SQL_Tricks_II#Conversion_between_hex_and_dec_numbers
Regards
Pavel
2013/12/31 Janek Sendrowski
> Hi,
>
> How can I realize the l
On 12/31/2013 01:09 PM, John R Pierce wrote:
On 12/31/2013 12:45 PM, peterlen wrote:
PostgreSQL has a geometric data type of "point". The format is listed
as (x,
y) but I am not sure if the X is to represent latitude or longitude.
I have
seen different systems that us X for either. Typically,
Hi,
How can I realize the line?
v_res := cast(x'v_tmp' as bigint);
v_tmp is a text variable with hex digits.
this works:
v_res := cast(x'6de14a8b478ac' as bigint);
I think its about quoting
Janek
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your s
John - Appreciate the response. The reason why I asked this question is
specifically for operations within PostGIS that will utilize the point
values and so it is pretty important that the point values are entered
correctly. Your description of X representing east/west and Y representing
north/so
Adrian - Thanks for the reply. The example was from
http://www.postgresql.org/docs/9.1/static/tutorial-populate.html with the
example of:
INSERT INTO cities VALUES ('San Francisco', '(-194.0, 53.0)');
That is not a valid coordinate but it is clear that they are trying to
declare it as longitude
On 12/31/2013 01:31 PM, Joseph Kregloh wrote:
ERROR: relation "sys_errors" does not exist
LINE 1: SELECT * FROM sys_errors ORDER BY created_ts DESC LIMIT 100;
^
** Error **
ERROR: relation "sys_errors" does not exi
On 12/31/2013 01:51 PM, Joseph Kregloh wrote:
So you have not upgraded the tablespaces. What is important to
remember is Postgres uses numbers to keep track of relations.
Part of the upgrade process involves changing the numbers that
point at relations. By manually
>
> So you have not upgraded the tablespaces. What is important to remember is
>> Postgres uses numbers to keep track of relations. Part of the upgrade
>> process involves changing the numbers that point at relations. By manually
>> dropping a 9.0 tablespace into a 9.3 data directory you have broke
On 12/31/2013 01:31 PM, Joseph Kregloh wrote:
ERROR: relation "sys_errors" does not exist
LINE 1: SELECT * FROM sys_errors ORDER BY created_ts DESC LIMIT 100;
^
** Error **
ERROR: relation "sys_errors" does not exi
>
>
>> ERROR: relation "sys_errors" does not exist
>> LINE 1: SELECT * FROM sys_errors ORDER BY created_ts DESC LIMIT 100;
>>^
>> ** Error **
>>
>> ERROR: relation "sys_errors" does not exist
>> SQL state: 42P01
>> Character: 15
>>
>
> sys_errors is a table
On 12/31/2013 12:45 PM, peterlen wrote:
PostgreSQL has a geometric data type of "point". The format is listed as (x,
y) but I am not sure if the X is to represent latitude or longitude. I have
seen different systems that us X for either. Typically, coordinates should
be read as lat/long but I
On 12/31/2013 12:45 PM, peterlen wrote:
PostgreSQL has a geometric data type of "point". The format is listed as (x,
y) but I am not sure if the X is to represent latitude or longitude. I have
seen different systems that us X for either. Typically, coordinates should
be read as lat/long but I
On 12/31/2013 12:25 PM, Joseph Kregloh wrote:
I did a bit more experimenting today. First test:
/opt/bin/pg_upgrade -d /usr/local/pgsql/data -D
/usr/local/pgsql_93/data/ -b /usr/local/bin/ -B /opt/bin/ -p 5452 -P 5451
It completes successfully, however I still have the user defined
tablespaces
PostgreSQL has a geometric data type of "point". The format is listed as (x,
y) but I am not sure if the X is to represent latitude or longitude. I have
seen different systems that us X for either. Typically, coordinates should
be read as lat/long but I have seen the opposite as well. An exampl
I did a bit more experimenting today. First test:
/opt/bin/pg_upgrade -d /usr/local/pgsql/data -D /usr/local/pgsql_93/data/
-b /usr/local/bin/ -B /opt/bin/ -p 5452 -P 5451
It completes successfully, however I still have the user defined
tablespaces inside the 9.0 data folder. So I manually moved
On Tue, Dec 31, 2013 at 10:55 AM, peterlen wrote:
> After logging into the PSQL Shell Script as a particular user and
> database, I
> want to display who my current user is and what database I am in as I may
> have forgotten who I am logged in as in order to make sure any commands are
> going to
Excellent. That works. Many thanks!
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/How-to-list-current-user-and-database-in-PSQL-tp5784928p5784932.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
--
Sent via pgsql-general mailing list (p
On 12/31/13 11:06, Bosco Rama wrote:
>
> Use the connect meta without arguments, i.e.
>
> xyz> \c
> You are now connected to database "xyz" as user "demo".
Hmmm. Scratch that. That actually does a reconnect. Probably not
what you want, especially is you are in the middle of a transaction. :-(
On 12/31/13 10:55, peterlen wrote:
> After logging into the PSQL Shell Script as a particular user and database, I
> want to display who my current user is and what database I am in as I may
> have forgotten who I am logged in as in order to make sure any commands are
> going to the right place. I
On 12/31/2013 10:55 AM, peterlen wrote:
After logging into the PSQL Shell Script as a particular user and database, I
want to display who my current user is and what database I am in as I may
have forgotten who I am logged in as in order to make sure any commands are
going to the right place. In
After logging into the PSQL Shell Script as a particular user and database, I
want to display who my current user is and what database I am in as I may
have forgotten who I am logged in as in order to make sure any commands are
going to the right place. In Oracle's SQLPlus you can do something lik
I'd like to announce the initial release of the logging extension I've been
working on for some time now.
http://pgxn.org/dist/cyanaudit/
Cyan Audit is a PostgreSQL extension for in-database audit logging of DML
that occurs in your database. It allows for forensics to be performed on
past data mo
This should help...
In each temporary table convert the time parts to a timestamp, then create an
index on each of these, then join on the timestamp.
ALTER table mmc add column timer timestamp without time zone;
UPDATE mmc set timer = (utc_year || '-' || utc_month || '-' || utc_day || ' '
||
On Tue, Dec 31, 2013 at 5:33 AM, Moshe Jacobson wrote:
>
> On Mon, Dec 30, 2013 at 2:02 PM, Tom Lane wrote:
>>
>> I've committed fixes for these
>
>
> Will these fixes appear in 9.3.3?
Yes.
--
Michael
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to yo
Jeff Silberberg wrote:
> Anyway, I Am now looking for new host instead of fixing this one..
I'm working for internet24.de, a hosting - provider in germany. We are
support PostgreSQL in our shared hostig ;-)
Andreas
--
Really, I'm not out to destroy Microsoft. That will just be a completely
un
Sergey Konoplev wrote:
> On Mon, Dec 30, 2013 at 12:27 AM, Albe Laurenz
> wrote:
>> Joe Van Dyk wrote:
>>> If I run "COPY (select * from complicate_view) to stdout" on the standby,
>>> I've noticed that sometimes
>>> halts replication updates to the slave.
>>>
>>> For example, that's happening r
33 matches
Mail list logo
