Asked  8 Months ago    Answers:  5   Viewed   22 times
<select class="txtbx1" name="country" disabled>

<option value='FR' >FRANCE</option><option value='CH' selected>SWITZERLAND</option>

the above code is inside a form whose method is post

but echo $_POST['country'] is showing nothing.. on the other hand if I remove disabled from select $_POST['country'] is showing the correct result



This is how the disabled attribute works. When a form control is disabled, the value will be ignored when the form is submitted and the key will not be present in $_POST (or $_GET).

If you want the value to be present in the submitted data, but you don't want the user to be able to change the value on the page (which I imagine is what you are trying to acheive) use readonly="readonly" instead of disabled="disabled".


The <select> element does not have a readonly attribute. The above information still stands as it will work for <input>s and <textarea>s.

The solution to your problem here would be to disable the select and use a hidden input to send the value back to the server - e.g.

When the select is enabled:

<select class="txtbx1" name="country">
  <!-- options here -->

...and when it is disabled:

<select class="txtbx1" name="country_disabled" disabled="disabled">
  <!-- options here, with appropriate value having `selected="selected"` -->
<input type="hidden" name="country" value="value_of_field" />
Wednesday, March 31, 2021
answered 8 Months ago
<form method="POST" action="">
Wednesday, March 31, 2021
answered 8 Months ago

Assuming curl is installed and enabled on the server, you should be able to do something like:

$post_data = array(
    'name' => 'Your Name',
    'email' => '',
    'web' => '',
    'comment' => 'your comment',
$ch = curl_init();

curl_setopt($ch, CURLOPT_URL,"");
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $post_data);

curl_exec ($ch);
curl_close ($ch); 

Another alternative, and possibly a more flexible one would be to use Guzzle which will handle the http request and response for you.

As a side note, the script you posted is currently dangerously written, you are directly inserting user provided data into the database without escaping it (e.g. by using mysql_real_escape_string), ideally you should be using a prepared statement via PDO or similar

Saturday, May 29, 2021
answered 5 Months ago

PostgreSQL automatically creates indexes on primary keys and unique constraints, but not on the referencing side of foreign key relationships.

When Pg creates an implicit index it will emit a NOTICE-level message that you can see in psql and/or the system logs, so you can see when it happens. Automatically created indexes are visible in d output for a table, too.

The documentation on unique indexes says:

PostgreSQL automatically creates an index for each unique constraint and primary key constraint to enforce uniqueness. Thus, it is not necessary to create an index explicitly for primary key columns.

and the documentation on constraints says:

Since a DELETE of a row from the referenced table or an UPDATE of a referenced column will require a scan of the referencing table for rows matching the old value, it is often a good idea to index the referencing columns. Because this is not always needed, and there are many choices available on how to index, declaration of a foreign key constraint does not automatically create an index on the referencing columns.

Therefore you have to create indexes on foreign-keys yourself if you want them.

Note that if you use primary-foreign-keys, like 2 FK's as a PK in a M-to-N table, you will have an index on the PK and probably don't need to create any extra indexes.

While it's usually a good idea to create an index on (or including) your referencing-side foreign key columns, it isn't required. Each index you add slows DML operations down slightly, so you pay a performance cost on every INSERT, UPDATE or DELETE. If the index is rarely used it may not be worth having.

Sunday, June 27, 2021
answered 4 Months ago

Does it matter which columns I select?

No, it doesn't matter. Even if SELECT 1 FROM table WHERE ... FOR UPDATE is used, the query locks all rows that meet where conditions.

If the query retrieves rows from a join, and we don't want to lock rows from all tables involved in the join, but only rows from specific tables, a SELECT ... FOR UPDATE OF list-of-tablenames syntax can be usefull:

I can't do a select in a function without saving the data somewhere, so I save to a dummy variable. This seems hacky; is it the right way to do things?

In Pl/PgSql use a PERFORM command to discard query result:

Instead of:

SELECT 1 INTO dummy FROM my_table WHERE userid=v_1 LIMIT 1 FOR UPDATE;


PERFORM 1 FROM my_table WHERE userid=v_1 LIMIT 1 FOR UPDATE;
Sunday, August 8, 2021
answered 3 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :