Mohamedyousof wrote
> UPDATE "Categories" SET ("Name") = ('test') where "ID" = 28;
No parenthesis:
UPDATE "Categories" SET "Name" = 'test' WHERE "ID" = 28;
This presumes you truly need the double-quotes. It this does not work try
removing the double-quotes around "Categories", "Name" and "ID" a
David Johnston wrote
>
> Mohamedyousof wrote
>> UPDATE "Categories" SET ("Name") = ('test') where "ID" = 28;
> No parenthesis:
>
> UPDATE "Categories" SET "Name" = 'test' WHERE "ID" = 28;
>
&
Chris Campbell-14 wrote
> My question is, where is the Application name column pulling its data
> from?
http://www.postgresql.org/docs/9.2/interactive/runtime-config-logging.html
Section 18.8.3
"application_name"
Issue a:
SET application_name = 'my_application';
command upon establishing a c
Csanyi Pal wrote
> Now, I don't understand, why changes pgAdminIII the entered value,
> namely from
> [2013-09-01,2013-11-12]
>
> to
>
> [2013-09-01,2013-11-12)
>
> automatically??
>
> I want to enter [2013-09-01,2013-11-12] because I want to to set this
> range with inclusive bounds.
Are you
Csanyi Pal wrote
> Hi,
>
> I have installed PostgreSQL 9.2 on my desktop machine, and
> pgAdmin III version: 1.16.1.
>
> I'm being creating a new database with daterange type.
>
> When I'm trying to enter in the 'Edit Data - PostgreSQL' window in the
> first raw a range of data:
>
> '2013-09-01
Kanitchet Vaiassava wrote
> (Bug) Numeric fault calculation
>
> postgresql : 714.355
> long division method: 714.356
FYI:
My prior posts use a result cast "::text" in order to avoid any kind of
interaction with how pgAdmin would handle numbers. This is not a pgadmin
bug/issue it is
Guillaume Lelarge-3 wrote
> If you use a floating
> point datatype (which is what happens when you don't specificy the
> type),
I covered this in my prior post but per the documentation this is incorrect.
http://www.postgresql.org/docs/9.0/interactive/sql-syntax-lexical.html#SQL-SYNTAX-CONSTAN
Guillaume Lelarge-3 wrote
> On Sun, 2013-06-16 at 04:59 -0700, Chirag Mittal wrote:
>> Dear Kanitchet,
>>
>> Please try this
>>
>> SELECT (260739.94 * (1.00/365.00))::numeric(20,7)
>>
>> I am a beginner but I think we need to explicitly mention the "output"
>> format required to get accuracy.
>
